Re: [xml-dev] RESTful operations on document fragments

["\"John L. Clark\"" <jlc6@po.cwru.edu>]

Simon St.Laurent <simonstl@simonstl.com> wrote:
> The problem of resource granularity seems like a question that is
> starting to need a more general and at least somewhat flexible solution.

>  The early drafts of XLink did include some thoughts in this direction:
>
>  http://www.w3.org/TR/WD-xml-link-970406#sec5.2
>
>  'If the connector is "?XML-XPTR=", this signals an intent that the
>  entire locator is to be transmitted to the host providing the resource,
>  and that the host should perform the XPointer processing to extract the
>  sub-resource, and that only the sub-resource should be transmitted to
>  the client.'
>
>  But that vanished pretty early.  Maybe it's time to revive it.
>
>  Hmm... Internet-Drafts aren't that hard to prepare.  I'll have to think
>  about it.

I like this idea.  I think it'd be very useful to have a way to
specify to the content server that you want to address into the (XML,
possibly other non-relational) resource.  I would, however, like to
take this opportunity to engage in some fanciful rumination, if
you don't mind.  It seems to me that the common use for a URI's
query component is for unordered value to variable mappings (commonly
`foo=bar&baz=quux` and so on).  With respect to active URIs, this
seems analogous to the options of a command line[0].  So
"https://api.del.icio.us/v1/posts/get?tag=XML"; might look like
`del.icio.us-get --tag=XML` on the command line.  Could there be, or
even should there be, something analogous to positional arguments?

I think there is an interesting corner of the URI specification that
goes underused.  Every now and again, I toy with the idea of using
empty path segments as separators for the above purpose.  URI path
components with such segments would look like
</path/to/resource//positional/arg/0//.../positional/arg/N>.  I would
imagine then having one of these "positional argument" segment
sequences use XPointer syntax to identify sub-components of resources.
 This might look like
</path/to/XML/resource//xpointer(element(someID))>.  Of course, this
would require defining an additional XPointer escaping context that is
appropriate for escaping content within a path segment (in particular,
one that escapes the '/' character).

Naturally, this looks a lot like the "?XML-XPTR=" query variable; the
variable is named, and there are a few other important differences.
Those aside, something about the ability to use positional arguments
appeals to me, but it may just be my personal aesthetic.

>  I can always create abstraction layer upon abstraction layer.  They make
>  pretty piles, until they fall over.
>
>  I guess my basic surprise is that this seems like something that would
>  be frequently useful, worth having as standard equipment, but it isn't.

Although I would like to use one of the above approaches, in practice
the current application that we are building does add a URI
abstraction layer; the system has not yet fallen over, and I don't see
any indication that it will.  Perhaps one reason is that there have
not been any overt requirements for addressing sub-sub-resources (and
so on), so we just end up with one abstraction layer.  Or perhaps it
is reasonable to note that sub-sub-resources are also sub-resources
(such as when giving elements IDs).  In any case, we have two (or
three) approaches here, and I'm curious as to which might be
considered the most RESTful, and why?  Which has the most desirable
properties?  Which approach best identifies the target sub-resource,
and why?

> Maybe the 1997 XLink approach is worth further pursuit.  (And on
> reflection, that's probably why I asked the question here - this list
> has had related conversations in the past.)

I think that it is, and I want to provide my encouragement.

Take care,

   John L. Clark

[0] http://docs.python.org/lib/optparse-terminology.html

--
PLEASE NOTE that this message is not digitally signed. As a result,
you have no strong evidence that this message was actually sent by me.
Upon request I can provide a digitally signed receipt for this message
or other evidence validating its contents if you need such evidence.