[DAS2] xml:base subtleties

[Andrew Dalke]

DAS2 support extensions through non-das2: namespaced XML elements.

<FEATURES>
   <FEATURE uri="feature1">
      ...
      <dalke:IMAGE xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
   </FEATURE>
</FEATURES>

DAS2 supports xml:base

<FEATURES xml:base="http://biodas.org/path/to/server1/">
   <FEATURE xml:base="/path/to/server2/" uri="feature1">
      ...
      <dalke:IMAGE xml:base="../server3"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>

For both IMAGE and MOVIE the link attribute is expanded
via the enclosing xml:base, for clients which know about
those elements.

When a client gets the record it's supposed to treat
any extension elements as character blobs and send them
opaquely in the writeback.

At least that's my thought.  I don't know if you all have
a different opinion.  I believe this approach gives the
best chance for compatibility so a server can serve things
the client doesn't know about and still let the client do
writeback for the things it does know about.

(Another approach is to send diff/edit commands to the server,
which we decided against.  For good reasons.)


Suppose there's a change to the above record.  What
does the client send back?  The following is obviously
valid but it requires the server keep track of the
xml:base attributes at different levels

<FEATURES xml:base="http://biodas.org/path/to/server1/">
   <FEATURE xml:base="/path/to/server2/" uri="feature1">
      ...  change to the 'name' field ...
      <dalke:IMAGE xml:base="../server3"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>

The following should also be valid.  It collapses the top-level
xml:base into the FEATURE-level.

<FEATURES>
   <FEATURE xml:base="http://biodas.org/path/to/server2/" uri="feature1">
      ...  change to the 'name' field ...
      <dalke:IMAGE xml:base="../server3"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>

It's even possible to get rid of xml:base for all the fields
the client knows about.  This will be most likely for servers
which convert the XML into a class/object model and flatten
the incoming URIs while doing so.

<FEATURES>
   <FEATURE uri="http://biodas.org/path/to/server2/feature1">
      ...  change to the 'name' field ...
      <dalke:IMAGE xml:base="????"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/" 
xml:base="???"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>

The question is, what does the client do with the non-DAS
elements where it doesn't know what to do.  Should it insert
xml:base attributes in them?

Or is the best practice to persist the xml:base on a per-feature
basis and always include the xml:base in the writeback?

My feeling is it's the last paragraph.  I really want the
clients to treat extensions as mostly opaque things.  (They
can assume it's okay to remove <? processing ?> instructions,
comments, etc. and collapse whitespace.)


Okay, now the other way around.  Suppose the server is configured
to treat unknown extensions as blobs.  What does it do with
the xml:base attributes?  In the following the DAS2 URIs are
all absolute URIs so the DAS2-specific code never even looks
at the xml:base attributes.


<FEATURES xml:base="http://example.com/A/B/C/">
   <FEATURE xml:base="../M/N/"
               uri="http://biodas.org/path/to/server2/feature1">
      ...  change to the 'name' field ...
      <dalke:IMAGE xml:base="../../Y/Z"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>


Normally on writeback the server inserts xml:base attribute
into the FEATURES (and FEATURE in this case) document.  It
can't when the client sent in the above structure.  At best
it can collapse the xml:base attributes inward so they only
apply to the non-DAS elements.  That is, turn the above into

<FEATURES xml:base="http://example.com/A/B/C/">
   <FEATURE xml:base="../M/N/"
               uri="http://biodas.org/path/to/server2/feature1">
      ...  change to the 'name' field ...
      <dalke:IMAGE xml:base="http://example.com/A/B/Y/Z"
              xmlns:dalke="http://dalkescientific.com/"
              link="picture.png" title="me!" />
      <dalke:MOVIE xmlns:dalke="http://dalkescientific.com/"
              xml:base="http://example.com/A/B/M/N/"
              link="spam.mov" title="me eating spam!" />
   </FEATURE>
</FEATURES>


That's not complicated but it is finicky.

To summarize:
   if we have xml:base and support for blob elements then
     1) the client must preserve xml:base on writeback
     2) the server must fix up the writeback to make sure
       it does not conflict with the server's use of xml:base

					Andrew
					dalke at dalkescientific.com