Re: Data Model

On 29.08.2010 21:05, David Nuescheler wrote:
> Hi Julian,
>
> thanks for kickstarting the conversation...

:-)

I was planning to actually insert my opinion as well, but was waiting 
for other's views first.

Here we go:

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

Yes.

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

Indeed. As we have seen in WebDAV and JCR, it can be added later on 
without affecting existing code (just be a bit careful when phrasing 
things, not confusing the identifier with the thing being identified).

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

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

Yes, but I think we need to require that percent encoding actually is 
used to encode UTF-8 sequences. In WebDAV, the interop problems between 
*nix boxes (octet sequences as filenames) and Windows boxes (Unicode) 
have been painful.

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

Yes. I also believe that special casing links would be good.

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

Would a zero length content work as well?

Best regards, Julian

Received on Sunday, 29 August 2010 19:28:49 UTC