W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2010

Re: Data Model, as seen from WebDAV

From: David Nuescheler <david@day.com>
Date: Thu, 23 Sep 2010 19:42:17 +0200
Message-ID: <AANLkTinif46QFpdhsASZYBAGuEThFyJgwEM-m+Q8-SBC@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
Hi Julian,

> Related to naming of resources and properties we *also* have to think about
> whether they should share the same space of names.
I would vote for sharing the same space, since it makes it more
compatible and in my experience it really adds complexity having two
namespaces.

> In WebDAV, properties are not exposed as HTTP resources (*), instead the
> special HTTP method PROPFIND is used. Thus, collisions between properties
> and children of a resource are no concern: a folder could have both a child
> resource "foobar" and a property "foobar".
> (*) Yes, that's one of the big issues with the WebDAV approach; but maybe we
> can fix this by exposing WebDAV properties over HTTP GET in the future.
> In JCR, the same space of names is used for resources and properties, thus
> once the name of a child resource and a property collide, it depends on the
> type of API which one you'll get. This is something we need to avoid.
Agreed. As a historical comment, I think we ended up in the situation
with JCR since XML also has separate name spaces for elements and
attributes and we offer a round tripping of XML into JCR and back.

> [[ Note: XPath uses a path-like syntax to address both elements and
> attributes, but easily works around this because @ is not valid in element
> names; similarly, it takes advantage of other reserved characters such as
> "(" and ")" to disambiguate between function and element names ]]
> In David's JSOP slides, we see examples similar to:
> var collection1 = {
>  "createdby" : "user1",
>  "child1" : {
>    "createdby" : "user2"
>  },
>  "child2" : {
>    "createdby" : "user3"
>  }
> };
> That has the same problem as JCR; member names and property names can
> collide.
I would argue that this is not a problem but a feature. As much as in
a filesystem files and folders share the same namespace it one should
apply the same to properties and resources. More importantly as you
indicate the JSON limitation would suggest a single namespace as well.

> I think we'll need to disambiguate by introducing intermediary objects such
> as "props" and "members", or even model the collection containment using a
> reserved property name.
Since I see simplicity as one of the main reasons to do this effort I
would rather not complicate the simple case where we don't have a
collision just because there might be a chance of an edge. Especially
since I don't think there is any real value in the additional
flexibility that would allow "same named" properties and resources.

regards,
david
Received on Thursday, 23 September 2010 18:04:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 September 2010 18:04:35 GMT