Subject: Re: [Simple] Namespaces and XCAP

From: jari urpalainen <[email-masked]>
Date: Tue, 01 Feb 2005 09:23:42 +0200

On Mon, 2005-01-31 at 15:55 -0500, ext Jonathan Rosenberg wrote:
> 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.
> 
> 

In principle I am in favor of 5A. However, I have a difficulty
understanding why we should use a different syntax than what xpointer
spec has ?

http://www.w3.org/TR/WD-xptr

xmlns(x=http://example.com/foo) xpointer(//x:a)

Furthermore, there seems to be a tendency to use fragment identifiers,
so I would propose to use them.

This leads to another issue that has to be addressed as well, i.e. the
namespaces in the request body. Do we still use the namespace context
from the document or do we use definitions from the xpointer context or
do we use the body context when appending new data ?

Some interesting cases arise when we want to e.g. append a new node like
this

xmlns(x=http://example.com/foo) xpointer(/x:root/x:a)

where body equals

<a xmlns="http://example.com/foo">
<foo/>
</a>

Given the document root had the same prefixed namespace definition how
should the xcap server append this ?

Character encodings should also be addressed somehow as we are heading
towards better "blind" updates, i.e. if the document uses e.g. UTF-8
encoding and the client uses charset=iso-xxx, what would be the result
of an append operation ?

Probably there might be some other implications as well...
br,
Jari 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 02:43:45 -0500

inline.

> understanding why we should use a different syntax than what xpointer

Why is it different? I was proposing to use the xmlns xpointer 
expression exactly as defined.

> xmlns(x=http://example.com/foo) xpointer(//x:a)

Oh, so you are saying ditch the whole xpath thing in favor of xpointers 
for element naming?

My read of xpointer was that it was primarily aimed at solving a broader 
problem even than path, namely being able to identify points and text 
ranges within an xml document. We don't need or want that. I also don't 
know how to map this easily into URI's, whereas xpath is easily mapped. 
Since the ONLY thing xpointer() would give us is syntax, what is gained??

> so I would propose to use them.

URL fragment identifiers? AS in #fragment-id? As an alternative to the 
~~ approach in the URI?

> do we use the body context when appending new data ?

Document. The body is either the document itself or a piece of it, in 
which case the namespace bindings have to be from the document.

> should the xcap server append this ?

What is the ambiguity? The URI provides the bindings for the URI 
evluation against the document. It resolves to no existing element. 
Great. The parent element is located (again using the URI namespace 
binding context), and the content of the request is inserted as its 
child. It happens to reset the default namespace. Perform a GET against 
that same URI. It now returns what was just selected. Everything is fine.

If the element had redefined the default namespace to something else, 
the URI would no longer select the element just inserted, and the 
operation wouldn't meet the GET(PUT(X))==X property and be rejected.

> encoding and the client uses charset=iso-xxx, what would be the result

Good question. This came up as a comment from others during last call. I 
have already added text to my working copy which says that this would be 
rejected. An error code has been defined for this too. Indeed, the 
current text mandates UTF-8 so anything but that in the charset is rejected.

-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

---

From: jari urpalainen <[email-masked]>
Date: Wed, 02 Feb 2005 12:08:39 +0200

> Oh, so you are saying ditch the whole xpath thing in favor of xpointers 
yes definitely.

> Since the ONLY thing xpointer() would give us is syntax, what is gained??
yes it does extend basic xpath with these ranges and points and of
course I don't want to propose to use them just this xcap scoped
restricted xpath. I just don't want yet another buggy uri selector as
w3c has already found a proper model for selectors with xpointers.

> URL fragment identifiers? AS in #fragment-id? As an alternative to the 
yes. this seems to be w3c preference (xlink, xinclude etc.) and I think
we should really follow that.

> which case the namespace bindings have to be from the document.
so the document context should still be followed strictly. 
> operation wouldn't meet the GET(PUT(X))==X property and be rejected.
my aim was to raise a question whether to allow a more xml-ish way of
allowing e.g. the server to decide when to drop duplicate namespace
definitions or change e.g. default namespace usage to a prefixed version
etc. Granted, I don't have a clear view on this, but I am just afraid
that we may miss some useful usecase given this tight schedule.
> current text mandates UTF-8 so anything but that in the charset is rejected.
Sorry I may have missed that thread, but I'll hope this means that the
server has to support UTF-8 but may support UTF-16, ISOxxx, right ?

br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Feb 2005 01:32:35 -0500

inline.

>>Oh, so you are saying ditch the whole xpath thing in favor of xpointers 

Well, I am reluctant for such a significant change at this point. I 
don't see what is gained. How is:

xpointer(/doc-root/el1/el2)

better than:

/doc-root/el1/el2

except that the former is harder to map into a URI and thus harder to 
use with xcap?

> w3c has already found a proper model for selectors with xpointers.

Xpointers uses xpath directly but extends it in ways we don't need, and 
adds syntax that is cumbersome for us. So, if we stick with the current 
xpath-based model, what kind of "bugginess" does this introduce? Are you 
saying that our current model is buggy?

> we should really follow that.

I don't understand the proposal. If you want to make a major change in 
direction here you need to provide a concrete proposal.

> that we may miss some useful usecase given this tight schedule.

I don't know how to react to this; we can't change or improve our 
approach unless there is a specific problem you are seeing.

> server has to support UTF-8 but may support UTF-16, ISOxxx, right ?

My current working copy explicitly mandates UTF-8, and nothing else. 
This is based primarily on the view that nearly all xml protocols we've 
been producing in the sip/simple community at least are utf-8.

Do you feel we need to support other charsets?

-Jonathan R.

---

From: jari urpalainen <[email-masked]>
Date: Thu, 03 Feb 2005 11:11:21 +0200

> except that the former is harder to map into a URI and thus harder to 
I don't know the reasons why w3c chose the model they have with the
current set, i.e. this bare-name and schemes: element(), xmlns() and
xpointer() stuff. However, it happens to solve the namespace problem
properly with a standard way. I really dislike to introduce a model that
is almost valid xpointer. So we had almost valid xpath 1.0 and now
almost valid xpointer. 

One complain about the current approach was that you can't use a
standard xpath library. If you'll use your proposal you can't either use
a standard xpointer library. And still with a standard xpath library
you'll have to do some tweaking.

I'll agree this is a significant change and at least I don't know of all
the implications that may arise, sorry.

> direction here you need to provide a concrete proposal.

Some reference from "The XML Bible, 2nd Edition"

http://www.cafeconleche.org/books/bible2/chapters/ch20.html

Just quoting examples from the above reference:

http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))
http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(descendant::language[position()=2])
http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf
http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/child::spec/child::body/child::*/child::language[2])
http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/spec/body/*/language[2])
http://www.w3.org/TR/1998/REC-xml-19980210.xml#/1/14/2
http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF"))

I don't understand what is so hard in this mapping ? Sure, we just need
a small subset of this, but already xcap bnf is a subset of xpath,
what's the problem doing that with xpointer, just take what is needed
but use a compatible reference.

If w3c didn't have anything like this, I wouldn't object doing one of
our own, but I see no point in reinventing the wheel. 

> approach unless there is a specific problem you are seeing.
Agreed. Once we are on this "blind" update track I am e.g. uncertain how
to deal with the namespace definitions in the body, just like in the
example that I gave. We can certainly stay with the document context
here, because I don't want to delay this work because of this.
> Do you feel we need to support other charsets?
Personally I don't need e.g. UTF-16 but in some languages it results in
shorter documents. However, I doubt that we'll have to mandate that. 

br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Feb 2005 08:37:38 -0500

inline.

> is almost valid xpointer. So we had almost valid xpath 1.0 and now

With the model I am proposing the URI can be trivially transformed into 
a valid xpointer expression by wrapping the node selector inside xpointer().

Once you do that, in what wa you "standard" xpointer implementations not 
be usable?

> standard xpath library.

we are fixing that with the namespace proposal.

>  If you'll use your proposal you can't either use
> a standard xpointer library. 

per above, why not?

> And still with a standard xpath library

can you elaborate??

> http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF"))

THis won't work for us at all.

As you know fragments are evaluated on the CLIENT side. That is why we 
discarded the usage of fragments to begin with.

> but use a compatible reference.

It doesn't work because the fragments are evaluated on the client side. 
In the URI above, the fragments would not even be passed to a server. We 
need them to be passed to the server. We could use a query string, but 
that brings up the whole specter of issues we had in another thread 
about how we then break the architectural model on which xcap is built.

> our own, but I see no point in reinventing the wheel. 

Hopefully I have explained that we cannot use the approach above.

> to deal with the namespace definitions in the body,

Again - I don't understand the problem you are pointing too. Can you 
give an example where there is uncertainty.

  just like in the
> example that I gave. 

I didn't see the problem in the example you gave. Behavior seemed well 
defined.

> shorter documents. However, I doubt that we'll have to mandate that. 

Since we are primarily dealing with documents defined to be interpreted 
by automata, and furhter documents oftentimes standardized here in ietf, 
free-form text is not likely to be a common part of the definition.

-Jonathan R.

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 3 Feb 2005 15:48:54 +0100

(As WG chair)

As you know, this draft has gone through WG last call and IETF last  
call. Unless you have identified show stoppers or bugs in the  
specification, please accept the consensus that was reached in the WG.

It is too late to argue personal taste.

Regards,
Hisham

On Feb 3, 2005, at 10:11 AM, jari urpalainen wrote:

> http://www.w3.org/TR/1998/REC-xml 
> -19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF"))
>

---

From: jari urpalainen <[email-masked]>
Date: Thu, 03 Feb 2005 16:57:56 +0200

> discarded the usage of fragments to begin with.

oops, sorry being stupid... That said I still don't feel comfortable
with the mixture of xpointer and xpath. Sorry for generating unnecessary
noise...
br,
Jari

---

From: jari urpalainen <[email-masked]>
Date: Fri, 04 Feb 2005 07:56:38 +0200

> It is too late to argue personal taste.
ok, I'll stop whining about the syntax. Just one minor editorial
comment. Imo, it is worth mentioning in the draft (sorry Jonathan if it
already exists) that if implementations utilize standard xpath or
xpointer libraries: 
1. if the xpath library has "registration" apis for namespaces uris and
prefixes they can be used in location step parsing.
2. if the xpath library doesn't support those extensions, i.e. it is
fully xpath 1.0 compatible, the server/client may have to change the
location step request from pref:foo to *[local-name()="foo"][namespace-
uri()="uri for pref"]
3. if xpointer library is being used in evaluation step parsing the
evaluation step request has to be changed so that xpath-part is
encapsulated within xpointer().
br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Feb 2005 09:41:23 -0500

inline.

> encapsulated within xpointer().

Generally speaking, this kind of implementation specific guidance is not 
something we put in specifications. The APIs tend to evolve and change, 
but the RFC is fixed.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Feb 2005 10:05:41 -0600

If you can compile enough things like this, putting them in an 
informational
"Implementer's Guide" draft would be a good thing.

RjS

On Feb 4, 2005, at 8:41 AM, Jonathan Rosenberg wrote:

>> xpointer libraries: 1. if the xpath library has "registration" apis 
>> for namespaces uris and
> Generally speaking, this kind of implementation specific guidance is 
> not something we put in specifications. The APIs tend to evolve and 
> change, but the RFC is fixed.
>
> -Jonathan R.
>
>
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Feb 2005 10:05:52 -0500

While working through the text, and based on some comments Jari made, I 
have a variation on option 5 which might be better still:

> CHOICE C: as part of a path segment that corresponds to an element, 

CHOICE D: as part of a query string

We had a thread previously based on Lisa's comments about using the 
query string for the WHOLE xpath expression. I still think that is a 
fundamental change to the architecture of xcap. However, the namespace 
bindings are a different thing. They aren't part of the document naming 
at all, really; they provide additional context that allows the URI to 
be evaluated. As such, they are more appropriately placed in a query 
string, I think. This would look like:

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

a major benefit of this approach is that, when only the default 
namespace bindings are needed, the query string can be absent entirely. 
Omitting the bindings is more troublesome in the previous approach, 
since it would leave an empty path segment.

The only drawback is the potential issue that we discussed a long time 
back regarding query strings; they might cause a problem for some 
proxies in conjunction with PUT. Subsequent discussions indicated this 
may not be a real issue, so I am inclined to go this direction.

Comments?

-Jonathan R.