We are seeking your help in resolving the following issues OMA PAG encounters
while implementing XCAP: namespace binding and element insertion.
OMA PAG kindly requests that IETF investigate the presented problems and
proposed solutions in a timely manner so that these issues can be quickly
resolved and XDM Specifications can be stabilized and ready for certification.
OMA PAG kindly requests IETF informing us the result of their investigation.
2 Issue 1: Namespace Binding
2.1 Problem Statement
During OMA POC and XDM IOP, the following problems were reported:
(G1) Namespace (NS) binding for XML fragments sent between XDM clients and
(G2) XML documents in XDM servers cluttered with local namespace declarations
In OMA PAG internal discussions, it is noted that considering the nature of
scarce radio resources in wireless domain, it is essential that an XCAP
transaction should be accomplished without multiple queries and all XCAP
queries are constructed in such a way so as to minimize their lengths. As a
result, the following optimization goal should also be considered:
(G3) Optimize XCAP queries, i.e. minimizing query length and reducing needs to
have additional transactions prior to a GET or PUT
3 Issue 2: Element Insertion
3.1 Problem Statement
It is identified that there is difficulty in current XCAP to insert elements
in a sequence.
XCAP-07 Section 8.2.3 says,
â€œâ€¦.If the PUT request is for an element, the server inserts the content
of the request body as a new child element of the parent element
selected in Section 8.2.1. The insertion is done such that, the
request URI, when evaluated, would now point to the element which was
inserted. If the target selector is defined by a by-name or by-attr
production (in other words, there is no position indicated) the
server MUST insert the element after any other siblings. If a
position is indicated, the server MUST insert the element so that it
is the position-th element amongst all siblings whose name matches
This text is not clear in that;
ï‚Ÿ The meaning of 'siblings' in element by-name or by-attribute case is
confusing. It could be interpreted either as all elements under the same
parent element, or as elements under the same parent element whose name
ï‚Ÿ It is not described how to insert an element when there is no sibling
whose name matches NameorAny.
The above ambiguities cause the following problems for schema validation:
ï‚Ÿ When the element insertion request is made, the element can be inserted
either after the siblings whose name matches NameorAny or after the siblings
under the same parent elements.
ï‚Ÿ When the element insertion request is made against the instance document
that does not contain sibling with same NameorAny, the XCAP Server behaviour
is undefined. This problem applies to any element with or without attributes.
As described in section 7.4 in XCAP-07, it is noted that the positional
insertion can ease the above-mentioned problems. However, it is still
problematic if there is no existing element with same NameorAny.
Other Consideration and Recommendation:
Another issue is the unique identification those element without attribute yet
with multiple occurance.
Although it is recommended to design schema such that an element should have
attribute for unique element identification, there could exist scenarios that
elements are defined without such attribute. An example of such case is the
previous common-policy-04 schema design where multiple occurrence of <id>
element without any attribute was allowed under <identity> element. The latest
common-policy-05 schema has revised this but, it seems such scenarios could
still happen in the future.
4 Requested Action(s)
â€¢ OMA PAG WG kindly asks IETF(SIMPLE) to consider the presented problems.
OMA PAG would appreciate IETF informing us the course of action in regarding
to these problems.
The OMA PAG would like to thank IETF (SIMPLE) for their consideration and
response to this request and we look forward to future opportunities to work
Lu Chang, Ph.D.
On behalf of OMA PAG