Data Model

On 23.08.2010 15:58, David Nuescheler wrote:
> ...
> I guess my main take from this is that I completely agree that we need
> to separate the "model"-conversation from the
> "format/binding"-conversation.
> ...

Ok,

here's a list of things we need to consider (probably incomplete, feel 
free to add)

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).

1.2 Multiple containment: allowed in WebDAV through multiple bindings, 
in JCR through shared nodes. CMIS/AtomPub: not constrained anyway.

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).

1.4 Ordering: optional features in WebDAV and JCR.

1.5 Member naming: in WebDAV by path segment (URI syntax), in JCR per 
optional namespace name + path segment.

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


2. Properties

2.1 Cardinality: properties can only occur once on a resource, but there 
are ways to express lists (WebDAV, JCR)

2.2 Typing: optional in WebDAV (see RFC 4316). Set of predefined types 
in JCR (int, float, string, date, URI, ...)

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


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)


Best regards, Julian

Received on Friday, 27 August 2010 14:20:50 UTC