Data Model, as seen from WebDAV

Hi,

going back to my notes and David's feedback, we seem to be very close to 
use a profile of the WebDAV data model:

> 1. Collections
>
> 1.1 Hierarchy: WebDAV collections are hierarchical. A "direct" member of a
> collection has the parent collection's 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).

-> WebDAV model (hierarchical collection matching HTTP URI path syntax).

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

Not now.

> 1.3 Identification: WebDAV: the name 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/inserted).

-> WebDAV model (where index notation would be used if we want same-name 
siblings)

> 1.4 Ordering: optional features in WebDAV and JCR.

-> WebDAV model (RFC 3648)

> 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. URI syntax requires defining the character encoding for interoperability.

-> WebDAV, with a constraint that percent-encoded stuff needs to be NFC 
UTF-8; alternatively use Unicode (NFC?) and define the mapping to path 
segment when mapping to a URI.

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

-> WebDAV model

! This will make it tricky to map from/to RDF. Just saying.

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

-> WebDAV model, augmented with bits from RFC 4316, and restricting some 
forms (such as mixed XML content)

Open question: do we want types not directly available in JSON, such as 
links?

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

This will require some work; expanded names may be a bit heavy-weight; 
more feedback appreciated.

> 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 we have agreement that content *is* special and should not be 
shoved into a property. It's not entirely clear whether we need to model 
resources without content, and, if we do so, how we expose them over HTTP.

Best regards, Julian

Received on Wednesday, 8 September 2010 15:18:19 UTC