Re: Some thoughts on XCAP's resource architecture

Jamie Lokier wrote:
> ...
>>...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?)

Yes.

> Other things such as the charset in the <?xml?> declaration also need
> to be passed.  Any XCAP server will have a mechanism for extracting

Not necessarily.  A server could serve all fragments encoded in UTF-8 
and would never have to send an XML declaration.  Strictly speaking, it 
wouldn't need to send it as well if it's specified in the Content-Type 
response header.

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

That's not true. The relative references need to get resolved to 
whatever the *current* base URI is. The base URI may change due to 
entity inclusion and xml:base processing.

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

No, that's incorrect.

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

Yes, but as demonstrated, that's fixable.

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

No, that's incorrect.

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

That's what I already proposed (I think). Just clarify it in the spec, 
and there should be a problem with it.


Best regards, Julian


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

Received on Friday, 26 November 2004 09:12:17 UTC