W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Re: Some thoughts on XCAP's resource architecture

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 24 Nov 2004 16:17:53 -0800
Message-Id: <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org>
Cc: "HTTP working group" <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
To: "Alex Rousskov" <rousskov@measurement-factory.com>

>
>> A resource .... if the server supports WebDAV.
>
> I agree that editing some XCAP resources via WebDAV would be 
> difficult, but I think it would be still technically possible. Just do 
> not think of an XML document as a single file. Can you name a single 
> WebDAV feature that would be impossible to implement for most XCAP 
> resources?

Nope, no impossibilities -- just difficulties and undesirabilities.

>> 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.
>
> Why not? If XML document is a collection of individually-managed 
> nodes, I do not see a problem. As a simple example, imagine a CGI 
> script that assembles an XML document from 100 nodes, each stored in 
> its own file. As a more flexible example, imagine an XML-friendly 
> database that allows users to have user-defined attributes for every 
> XML query result (which is nothing but a "view" in a database 
> terminology).

It's manageable from a coding point of view, I'm sure we're all 
excellent coders.  It's not manageable from an ease-of-use, application 
design and GUI point of view, nor does it scale as far.  I really can't 
think how a GUI client/user can possibly manage all the ACLs on all the 
node resources -- the complexity is enormous if it's not scoped down 
somehow, and if it's not scoped down now, then the natural diversity of 
implementations will make it much harder to scope down later.

Lisa
Received on Thursday, 25 November 2004 00:18:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:36 GMT