Re: Data Model

Hi Julian,

thanks for kickstarting the conversation...

Here my initial take on the topics below.

> 1. Collections
> 1.1 Hierarchy: WebDAV collections are hierarchical. A "direct" member of a
> collection has the parent collections URI + one additional path segment. JCR
> same. This also means that relative paths do the obvious thing.
> CMIS/AtomPub: no constraints on the paths (AFAIU).
I think the WebDAV hierarchy approach is great and very important
since referencing by (relative) URL is core to basic web things.

> 1.2 Multiple containment: allowed in WebDAV through multiple bindings, in
> JCR through shared nodes. CMIS/AtomPub: not constrained anyway.
While I think that multiple containment is interesting, it is
definitely not at the top of my priority list.

> 1.3 Identification: WebDAV: the same of a resource within a collection is a
> unique identifier. JCR: same (except that for same-name-siblings, the array
> index may change when siblings are removed).
I think the WebDAV way works perfectly.

> 1.4 Ordering: optional features in WebDAV and JCR.
I think this is more important for fine-grained content since when we
talk about DOM-like structures that are persisted on the server of
course the sort order makes a big difference. (As a side comment:
mapping things to JSON in the back of my mind creates a bit of tension
here, since sort-order of JSON object is undefined, while all
implementations in browsers keep the sort-order, technically a JSON
parser is not obligated to do that...)

> 1.5 Member naming: in WebDAV by path segment (URI syntax), in JCR per
> optional namespace name + path segment.
I am not sure if we need a special (xml-like) namespace management, it
seems like a lot of overhead.

> 1.6 Name encoding: in WebDAV per spec ASCII (+ URI percent encoding), in JCR
> Unicode.
ASCII + URI encoding sounds great

> 2. Properties
> 2.1 Cardinality: properties can only occur once on a resource, but there are
> ways to express lists (WebDAV, JCR)
I think there is no need to change that.

> 2.2 Typing: optional in WebDAV (see RFC 4316). Set of predefined types in
> JCR (int, float, string, date, URI, ...)
If we look at the types in a browser javascript runtime it seems that
number, strings, boolean and Date seem like obvious candiates.

> 2.3 Naming: namespace name + local name (WebDAV, JCR)
Great.

> 3. Content
> 3.1 A single binary stream per HTTP in WebDAV (ignoring content negotiation
> for now which is tricky in authoring); modeled as binary property in JCR
> (with only conventions on naming)
I think in JCR we went all out and in my mind went too far with
binaries. I think I would be happy with having a single optional
binary stream.
More importantly though since this is about fine-grained information
the typical case will be having "no" binary at all, but just a tree of
properties (and "nodes?").

regards,
david

Received on Sunday, 29 August 2010 19:05:39 UTC