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

Re: Some thoughts on XCAP's resource architecture

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 26 Nov 2004 07:59:25 +0000
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
Message-ID: <20041126075925.GB1385@mail.shareable.org>

Julian Reschke wrote:
> >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.

I wasn't really thinking about normal web browsers, but rather clients
which can fetch resources from XML URIs and do useful things with
them, including following the URIs within the resources.

I'm thinking that the selectors work rather like the Range header in
some ways, but because they're in the URL it's reasonable to pass them
around among different programs.  For example, program A computes the
selector for a certain kind of XCAP query, and passes it to program B
which can retrieve the query result, which might contain references to
other resources (or even other query results).

> >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.

xml:base at the top-most tag is essentially document metadata.  (I
don't know about xml:base - is it allowed to appear anywhere?)

Other things such as the charset in the <?xml?> declaration also need
to be passed.  Any XCAP server will have a mechanism for extracting
and passing document metadata along with the response, and xml:base or
HTML's <base/> are just another part of that.

My main point is that when an XML document contains relative URIs,
those are relative to the _document as a whole_.

It's a conceptual thing.

The concept with XCAP is to address portions of an XML document.  The
XML rules and general practice mean that relative URIs appearing in
those portions are still _supposed_ to be relative to the whole document.

Therefore _conceptually_, the XCAP selectors should not change the
base path for relative URI resolution.

As it is now, an XCAP server would have to parse and modify the entire
selected portion to transform every relative URI, not just the single
base URI.

(Alternatively it could add its own xml:base to the served response,
but that might not be so reliably understood by recipients.)

This is because of the mismatch between the two concepts.

If XML URIs normally refered to subtrees in the XML, there would be no
mismatch, but they don't so there is.

-- Jamie
Received on Friday, 26 November 2004 07:59:50 UTC

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