[DAS] [DAS2] [Fwd: Re: Writeback implementation]

[Gregg Helt]

On Tue, Nov 4, 2008 at 2:24 AM, Gustavo Salazar <gustavo at nbn.ac.za> wrote:

>
> About the URI, can this URI be built using the uri in the base of the
> document + the uri atributte in the feature??


On Tue, Nov 4, 2008 at 4:05 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> When updating a feature the URI field can be whatever would go into the ID
> field, because both the server and the client need them to be the same. The
> ID/URI can be assumed to be relative to the base of the document in the same
> way as HTML relative links are processed. However, your example is a URI in
> its own right because it contains a colon but no /.
> ...
> So long as the absolute URI is derived in the same way for both servers you
> should be fine using whatever the "base server" uses.
>

Please note that in DAS2.0 the way to resolve relative URI references to
absolute URIs does not have to be "assumed".  As I mentioned before in this
thread:

> DAS/2.0 uses the XML Base specification <http://www.w3.org/TR/xmlbase/> to
> resolve relative URI references via xml:base attributes and/or the URI the
> document is a representation of.
>

Most software libraries that deal with URIs have a method to resolve a
relative URI reference against a base URI to to yield an absolute URI, so
that people don't have to hand-code the URI syntax and resolution rules.

Just to check, by "base of the document" do you mean the value of the
"xml:base" attribute in the root XML element, or the URL used to retrieve
the document?  According to the XML Base spec these are both incorporated in
a hierarchy of URI reference resolution, so it's possible to have a doc with
no "xml:base" attributes and still follow the XML Base spec.  However I
strongly recommend using an "xml:base" with an absolute URI value on the
root XML element of a doc to be more assertive about URI reference
resolution.  This is particularly important for DAS writeback, since at
least so far the URI to POST modifications to has been different than the
URIs to GET features/types/segments from.

      Gregg