Re: Some thoughts on XCAP's resource architecture

    So when I look at what a resource is across all these HTTP
    extensions and in HTTP itself, and what XCAP wants to do, it seems
    to me that more often than not the XML document is the resource,
    and the XML node should simply be a part of that resource.  We
    might think it would be nice to lock and add access control
    independently for every XML node but I don't think that will be
    manageable.  Certainly the per-node version history seems
    prohibitive while the ability to view past versions of the whole
    document (and revert to a past version) seems potentially useful.
    That's what I mean by the granularity problem with extensions --
    the choice of granularity for "what is a resource" has a lot of
    implications.

I admit that I haven't been following this discussion in great
depth.  But when I read this paragraph, I thought that maybe
the way to get at "node resources" is to treat them as a kind
of "Range".  Remember that the Range and Accept-Ranges headers
in RFC2616 are not necessarily limited to byte ranges, although
the spec is biased in that direction:

3.12 Range Units

   HTTP/1.1 allows a client to request that only part (a range of) the
   response entity be included within the response. HTTP/1.1 uses range
   units in the Range (section 14.35) and Content-Range (section 14.16)
   header fields. An entity can be broken down into subranges according
   to various structural units.

      range-unit       = bytes-unit | other-range-unit
      bytes-unit       = "bytes"
      other-range-unit = token

   The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
   implementations MAY ignore ranges specified using other units.
   HTTP/1.1 has been designed to allow implementations of applications
   that do not depend on knowledge of ranges.

One would hope that any extant implementation of Accept-Range
is smart enough to ignore something *like*

	Accept-Ranges: xcap-nodes

which would allow you to define a new specification for "ranges"
of XCAP XML nodes that would be backwards compatible with HTTP/1.1.

Then (if you pardon me for my complete ignorance of XCAP details)
you could replace Lisa's example:

	http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ 
		resource-lists/list%5b@name=%22friends%22%5d/entry

with something like

	GET /services/resource-lists/users/bill/fr.xml/ HTTP/1.1
	Host: xcap.example.com
	Range: xcap-nodes="resource-lists/list%5b@name=%22friends%22%5d/entry"

with the obvious syntax if you wanted to get multiple nodes at
once.

Like I said, this could be totally naive.

-Jeff

Received on Wednesday, 24 November 2004 19:54:10 UTC