Subject: [Simple] Namespaces and XCAP

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Jan 2005 15:55:40 -0500

Folks,

One of the issues that has come up during the last call period for xcap 
was the way namespaces are used during the URI matching operation. The 
way it works today is that the namespace contexts for evaluating the 
xcap URI are constructed as you traverse through the document. The 
namespace prefixes in the URI therefore need to be defined using 
namepsace bindings defined in the document itself.

This has two major drawbacks that have been pointed out:

1. it requires the XCAP client to have the document in hand ahead of 
time, just to know the namespace bindings

2. it prohibits the usage of existing off-the-shelf xpath libraries to 
support xcap. These libraries require namespace bindings to be provided 
PRIOR to the evaluation of an expression against a document.

We have in the past agreed that an xcap client must be able to perform 
operations like insertion of a buddy into a buddy list, without having 
the full buddy list document stored locally. The current matching rules 
make that impossible. That would seem to be a fairly significant 
limitation and therefore one that we need to address.

The alternatives are fairly limited. They are, as far as I can tell:

1. Server defined namespace bindings

The server can define bindings between namespace prefixes and namespace 
URIs in a separate document in the global tree. This requires the xcap 
server to track namespaces used in each instance document. When a new 
element, attribute or document is added, the server needs to scan those 
for new namespaces, and add bindings for them to the global document. 
Similarly, when an element, document or attribute is removed, the server 
would have to do reference checking to see if that namespace is still in 
use. If not, it would then remove the binding.

The binding document can be simple. For example, xpointer expressions 
would suffice:

xmlns(prefix1="http://namespace-uri-1")
xmlns(prefix2="http://namespace-2-uri")

A client would still need to have this namespace document in hand at all 
times. It is relatively small. However, the xcap client would need to 
know if it should change.

2. Client defined namespace bindings: separate document

Instead of having the server define bindings, each user has a document 
(in the user tree somewhere) that defines the bindings. The client 
themself creates this document. Thus, the client need only create 
bindings for the namespaces it plans on using in queries.

We still have the problem that, if multiple clients for the same user 
write this document, it needs to be kept up to date on the other clients 
(i.e., would require the config package).

Furthermore, it assumes that the user that performs a query is the same 
as the user that "owns" the document. This need not be the case. For 
example, my friends might be allowed to read entries off of my buddy list.

3. Implied namespace prefixes

Instead of the namespace bindings being obtained from a document, they 
could be well-known and constructed by algorithm. For example, an MD5 
hash of the namespace URI.

This approach has the benefit that no synchronization on a document is 
required. However, whenever the server processes a query against a 
document, it will need to obtain all of the namespace URIs in use in 
that document, and then hash them to obtain the namespace prefixes 
allowed in the queries. Thus, the work on the server is similar to 
proposal (1).

It would also result in extremely UGLY URIs, and long ones too.

4. Allow the namespace URI instead of a namespace prefix

In this approach, instead of hashing the namespace URI to obtain the 
namespace prefix, we simply allow the namespace URI itself to BE a valid 
prefix. This has none of the drawbacks of approach (3), except that it 
makes the URIs really, really, really long. Its also definitely a hack 
and something that is bending the rules a bit on XML namespaces.

5. Allow namespace bindings to be definde in the XCAP URI itself

In this approach, bindings between namespace prefixes and namespace URI 
are present in the xcap URI itself. The xpointer xmlns specification 
(http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to 
define these. As an example of how this might work:

http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/
    xmlns(foo="http://foo.example.com")/
    resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address

In other words, right after the ~~ delimiter, the next path segment is 
actually a namespace definition, binding the namespace prefix "foo" to 
the URI "http://foo.example.com". That prefix is then used later on in 
the URI.

The only question is where in the URI to place these definitions. Again, 
we only have so many choices that I can see:

CHOICE A: immediately after the ~~/, in the next path segment, which 
would contain all such definitions as xmlns xpointer expressions.

CHOICE B: anywhere in the URI, as a separate path segment

CHOICE C: as part of a path segment that corresponds to an element, 
attribute or document

I think the easiest thing is probably A.

The main drawback to this approach is that its inclusion in a path 
segment at all is a stretch to the definition of a path, but 
conceptually you are navigating into a namespace, and within that 
namespace, to elements and attributes.

It also leads to somewhat long-ish URI.

I would further propose that application usages define a default 
namespace for the xcap URI evaluation, so as to avoid defining those in 
each and every URI.

So, which to use? Considering the issues involved, I think the best 
option is 5(A).

Comments?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Jan 2005 17:42:55 -0500

I don't see any other sensible alternatives (one can always create even 
more contorted answers.)

There is one assumption that I think has to be made clear.  Namely that the 
client does know what namespaces are used in the document.  This makes 
reasonable sense to me, since the client will be preparing document 
fragments, and presumably understands the structure of the document it is 
working with.

Given that assumption, it seems to me that one rapidly concludes that the 
first four options are non-starters.  This leaves us with option 5.  5 A 
(xmlns() at the front of the path portion) seems to me a good 
compromise.  It covers most (but not all) documents.  And it keeps the 
parsing simple.  Allowing xmlns() anywhere would get really complicated.

Although I presume it is spelled out in W3C specs, we probably need to be 
clear about matching rules.  For example, suppose there is a namespace 
http://foospace.example.com.
In the document, in some portion of the document, this might be he default 
name space, and a tag <bar> from that namespace is used.
I would hope that the matching rules are such that if the XCAP client specified
/~~/xmlns(st="http://foospace.example.com")/.../st:bar
then assuming the omitted stuff got to the element containing the bar 
referencing that name space, then the st:bar would match the <bar> element.

Yours,
Joel

At 03:55 PM 1/31/2005, Jonathan Rosenberg wrote:
>was the way namespaces are used during the URI matching operation. The way 
>it works today is that the namespace contexts for evaluating the xcap URI 
>are constructed as you traverse through the document. The namespace 
>prefixes in the URI therefore need to be defined using namepsace bindings 
>defined in the document itself.
>
>1. it requires the XCAP client to have the document in hand ahead of time, 
>just to know the namespace bindings
>
>operations like insertion of a buddy into a buddy list, without having the 
>full buddy list document stored locally. The current matching rules make 
>that impossible. That would seem to be a fairly significant limitation and 
>therefore one that we need to address.
>
>times. It is relatively small. However, the xcap client would need to know 
>if it should change.
>
>Instead of having the server define bindings, each user has a document (in 
>the user tree somewhere) that defines the bindings. The client themself 
>creates this document. Thus, the client need only create bindings for the 
>namespaces it plans on using in queries.
>
>Furthermore, it assumes that the user that performs a query is the same as 
>the user that "owns" the document. This need not be the case. For example, 
>my friends might be allowed to read entries off of my buddy list.
>
>could be well-known and constructed by algorithm. For example, an MD5 hash 
>of the namespace URI.
>
>document, it will need to obtain all of the namespace URIs in use in that 
>document, and then hash them to obtain the namespace prefixes allowed in 
>the queries. Thus, the work on the server is similar to proposal (1).
>
>makes the URIs really, really, really long. Its also definitely a hack and 
>something that is bending the rules a bit on XML namespaces.
>
>actually a namespace definition, binding the namespace prefix "foo" to the 
>URI "http://foo.example.com". That prefix is then used later on in the URI.
>
>CHOICE A: immediately after the ~~/, in the next path segment, which would 
>contain all such definitions as xmlns xpointer expressions.
>
>The main drawback to this approach is that its inclusion in a path segment 
>at all is a stretch to the definition of a path, but conceptually you are 
>navigating into a namespace, and within that namespace, to elements and 
>attributes.
>
>I would further propose that application usages define a default namespace 
>for the xcap URI evaluation, so as to avoid defining those in each and 
>every URI.
>
>
>
>
>So, which to use? Considering the issues involved, I think the best option 
>is 5(A).
>
>Comments?
>
>Thanks,
>Jonathan R.
>
>
>--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Jan 2005 17:54:10 -0500

inline.

Joel M. Halpern wrote:

> There is one assumption that I think has to be made clear.  Namely that 
> the client does know what namespaces are used in the document.  This 
> makes reasonable sense to me, since the client will be preparing 
> document fragments, and presumably understands the structure of the 
> document it is working with.

Yes, I agree with that.

> 
> Given that assumption, it seems to me that one rapidly concludes that 
> the first four options are non-starters.  This leaves us with option 5.  
> 5 A (xmlns() at the front of the path portion) seems to me a good 

Which documents does it not cover? Even if a document has a namespace 
prefix re-defined in the middle of a document, it is still the case that 
each element and attribute is associated with a single namespace, and 
thus it should be possible to construct a URI with a node selector 
containing a prefix that maps to that namespace.

> 
> Although I presume it is spelled out in W3C specs, we probably need to 
> be clear about matching rules.  For example, suppose there is a 
> namespace http://foospace.example.com.
> In the document, in some portion of the document, this might be he 
> default name space, and a tag <bar> from that namespace is used.

Yes. Matching rules are done by expanding the prefixes (and defaults) to 
the full namespace URI and doing the comparisons that way. The xcap spec 
  specifies this by pointing to XML matching rules defined in the 
namespaces document.

Thanks,
Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Jan 2005 17:58:52 -0500

I had thought there would be coverage problems with reused name space prefixes.
But, as Jonathan points out, the XCAP client does not need to reuse 
prefixes even if the document does.
Hence, it seems even more clear that 5A is the right answer.

Thanks Jonathan.

Yours,
Joel

At 05:54 PM 1/31/2005, Jonathan Rosenberg wrote:
>first four options are non-starters.  This leaves us with option 5.
>each element and attribute is associated with a single namespace, and thus 
>it should be possible to construct a URI with a node selector containing a 
>prefix that maps to that namespace.

---

From: "Nelson Hung" <[email-masked]>
Date: Mon, 31 Jan 2005 15:27:51 -0800

I agree that 5(A) is the best option.

But one thing about default namespace, XPath Specification 1.0 explicitly
disallows the use of default namespace in an XPath expression...

http://www.w3.org/TR/xpath#node-tests

"A QName in the node test is expanded into an expanded-name using the
namespace declarations from the expression context. This is the same way
expansion is done for element type names in start and end-tags except that
the default namespace declared with xmlns is not used: if the QName does not
have a prefix, then the namespace URI is null (this is the same way
attribute names are expanded). It is an error if the QName has a prefix for
which there is no namespace declaration in the expression context."

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Jan 2005 20:29:05 -0500

This particular behavior in XPath 1.0 is IMHO a bug, and appears to have 
been corrected in XPath 2.0.

We are not normatively dependent on XPath, so we can do what we choose. 
I would propose that the application usage specify the default 
namespace. Otherwise, every single XCAP URI will need to contain a 
xmlns() xpointer expression declaring the default namespace for the 
documents, all of which are likely to use the target namespace as the 
default.

If we specify this, an xcap expression would be compatible with xpath 
2.0 I believe.

-Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Jan 2005 20:52:55 -0500

Sounds like a good idea to me.  It makes the normal case efficient, and 
matches the human expectation.

Yours,
Joel

At 08:29 PM 1/31/2005, Jonathan Rosenberg wrote:
>We are not normatively dependent on XPath, so we can do what we choose. I 
>would propose that the application usage specify the default namespace. 
>Otherwise, every single XCAP URI will need to contain a xmlns() xpointer 
>expression declaring the default namespace for the documents, all of which 
>are likely to use the target namespace as the default.
>
>If we specify this, an xcap expression would be compatible with xpath 2.0 
>I believe.
>
>-Jonathan R.