Re: Data Model, as seen from WebDAV

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 UTC