Re: Some thoughts on XCAP's resource architecture

Jamie Lokier wrote:
> ...
> No, actually there is an important reason why XCAP should be changed
> to be after the query part.
> 
> Clearly, generic origin XCAP servers should not have to analyse and
> transform the text of XML document - they should simply know how to
> select portions of it based on the XCAP selector.
> 
> With the "/~~/" syntax, think about what happens when an XCAP resource
> is fetched by non-XCAP aware software that is given an XCAP URL.  For
> example, a web browser told to view a subtree of some XML document.
> 
> That is one of the most useful reasons why XCAP is operating using
> HTTP URLs, after all.

I tend to disagree.

a) That you can use a browser is a useful feature for debugging, but 
unlikely to be the primary way XCAP would be used,

b) As long as each addressable fragment *does* get it's own URI, every 
solution will work equally well in a browser.

> Relative URLs appearing in the text of the subtree will be resolved by
> the browser including components of the selector.

...by any XML compliant recipient. Anyway, validaty of relative (URI) 
references is a problem, but a bigger one. Consider

<x xml:base="foo"><y/></x>

If you just address y, you'll loose the base URI information. So to make 
this work, an XCAP server would need to know about base URIs and 
xml:base anyway.

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760