Re: URIQA thwarted by WebDAV properties?

Patrick.Stickler@nokia.com (Patrick.Stickler@nokia.com) wrote:
> > Patrick.Stickler@nokia.com (Patrick.Stickler@nokia.com) wrote:
> > > > BTW2, apologies for the sensational subject. It made me 
> > > > cringe when I read it back the next day.
> > > 
> > > Please don't apologise. These are very good questions and it has been
> > > very beneficial to be able to cover them. I wish I had time to write
> > > more about URIQA, particularly about rational and experience putting
> > > it to work. Challenging questions are a good impetus to address alot
> > > of these key issues.
> > > 
> > > Bring it on!  ;-)
> > 
> > Oh oh, I have one! :-)
> 
> :-)
> 
> 
> > Ok, for starters I am a big fan of URIQA and have been since the
> > beginning.  I think it's an absolutely right-headed approach
> > towards getting the SW baloon off the ground.
> > 
> > My problem with it is that of implementation, and can be summed
> > up in three words:  Why not WebDAV?
> 
> When I was first looking at this problem, I did look at WebDAV,
> but found an imperfect match of semantics and application scope.
> 
> Either the semantics of the WebDAV methods were not exactly
> what was needed (albeit close) or included far more than I
> wanted to impose on URIQA-like implementations.
> 
> There was also some ambiguity about whether what URIQA means
> by 'resource' is what WebDAV means by 'resource' (all this 
> predates AWWW by quite a few years).
> 
> I don't have my notes handy at the moment and don't want to go
> into details based on a fuzzy memory. But in a nutshell, at the
> time, it didn't fit what I was needing/trying to do.
> 
> > Consider the following almost one-to-one mapping from URIQA's
> > adventurous forrays into HTTP extensions to WebDAV's.  All
> > definitions straight from the specs:
> > 
> > URIQA MGET
> >   Return a concise bounded description of the resource denoted by
> >   the request URI...
> > WebDAV PROPFIND
> >   The PROPFIND method retrieves properties defined on the resource
> >   identified by the Request-URI...
> > 
> > URIQA MPUT/MDELETE
> >   Add the statements contained in a concise bounded description of
> >   the resource, provided as input, to the (possibly empty) body of
> >   knowledge maintained about the resource denoted by the request
> >   URI.
> >   Remove the statements contained in a concise bounded
> >   description of the resource, provided as input, from the
> >   existing knowledge maintained about the resource denoted by the
> >   request URI.
> > WebDAV PROPPATCH
> >   The PROPPATCH method processes instructions specified in the
> >   request body to set and/or remove properties defined on the
> >   resource identified by the Request-URI.
> > 
> > URIQA handles a single kind of metadata, the CBD.  WebDAV can
> > handle any metadata that can be represented as XML.  Seems like
> > WebDAV addresses the bigger and more generally-applicable
> > problem of metadata at large and URIQA's CBD could fit pretty
> > nicely in here.
> > 
> > Not to mention all the extra stuff you get with WebDAV as well.
> > When you move a resource, you can just use the MOVE operation to
> > relocate the resource and its metadata seamlessly.
> > 
> > When you want to search the metadata, you can use the SEARCH
> > operation.  It's extensible so you can use any search grammer
> > you want to (think XQuery/RDQL/...)
> > 
> > And not to be outdone is the COPY operation.  It copies a
> > resource and its metadata from one location to another in a
> > single operation.  Even across hosts according to the spec,
> > though nobody implements that.
> 
> The way you present it above does motivate me to have another
> look at WebDAV, though I'm also beginning to get tinglings of
> memories of how/why these didn't quite fit the URIQA model.

WebDAV's dead properties and DASL SEARCH in my experience aren't
being put to use very prevelantly, which is a real shame IMHO.
If there's something that WebDAV can't provide for URIQA I'd say
there's probably a good case to be made for changing WebDAV so
it can.

Properties I don't think were originally intended to be
arbitrary XML metadata as much as just a mechanism for
representing heirarchical name/value pairs.  Considering
WebDAV's most recent spec is from 1999, I'm sure some things
have transpired that might warrent a fresh look.  Describing
resources with XML/RDF is I would say no less then essential for
any serious HTTP metadata layer.
 
> If/as I get some time in the next week or so, I'll try to
> revisit this and offer some comments. It's probably fair to
> add a section about WebDAV into the FAQ section of URIQA
> anyway...

Cool, thanks.

Eric

Received on Wednesday, 13 October 2004 00:33:09 UTC