W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Re: Some thoughts on XCAP's resource architecture

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 25 Nov 2004 09:26:36 +0100
Message-ID: <41A5973C.4050304@gmx.de>
To: Jamie Lokier <jamie@shareable.org>
CC: Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>

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
Received on Thursday, 25 November 2004 08:27:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC