[DAS2] relative URLs and xml:base in the writeback document

[Andrew Dalke]

On the topic of relative URLs ...

The writeback document contains FEATURE elements.  Because we
aren't supporting types I want to change the writeback document
so it looks like this

<WRITEBACK>
   <MESSAGE>Reason for the change</MESSAGE>
   <DELETE uri="foo" />
   <FEATURE uri="bar"> ... </FEATURE>
   <FEATURE uri="baz"> ... </FEATURE>
</WRITEBACK>

Problem #1: if I lift the existing FEATURE element definition
then the uri attributes may contain relative URIs and the
FEATURE element may contain an xml:base attribute.   We can
also have that "WRITEBACK" contains an xml:base attribute.

What happens if after all of that the writeback URI is still
a relative URL?  How does the server convert the relative URL
into an absolute one?  Does it use the writeback URL as the
document base?  That's the only one which comes close to making
sense, but it doesn't make much sense.  No client in its right
mind will deconvolute the feature uris to be relative urls
with respect to the writeback URL  (which, after all, may be
on an entirely different machine).


I checked the xml:base spec
   http://www.w3.org/TR/xmlbase/
and it refers to the URI RFC 2396
   http://www.ietf.org/rfc/rfc2396.txt

These are both defined in terms of document retrieval.  Eg,
>    If no base URI is embedded, the base URI of a document is
>    defined by the document's retrieval context.

This makes no sense in a POST document.

I think in this case it's fine to say "URIs in a writeback
spec must be absolute URLs".  Either they are written as
absolute URLs or they are made absolute in the context of
some xml:base defined in the writeback delta.

What say you all?
   A. all URIs in writeback must be absolute
       - don't support xml:base at all

   B. URIs may be relative but must be absolute once all
       enclosing xml:base attributes are included

   C. URIs may be relative and the writeback URL itself
       is used as the retrieval context

My vote is that the server implements B but that clients
will all do A.


Speaking of which, digging through the xml:base spec and
the history of our discussion I see that we are free to
define when xml:base is valid.  We could use it only on
the root element if we so desire.  Right now it can be on
any element.

The reason we have it on every element is from the influence
of this blog post:

http://norman.walsh.name/2005/04/01/xinclude
> Ugh.  In the short term, I think there's only one answer: update your 
> schemas to allow xml:base either (a) everywhere or (b) everywhere you 
> want XInclude to be allowed. I urge you to put it everywhere as your 
> users are likely to want to do things you never imagined.


					Andrew
					dalke at dalkescientific.com