- From: Julian Reschke <julian.reschke@gmx.de>
- Date: 2010年8月27日 16:20:01 +0200
- To: David Nuescheler <david@day.com>
- CC: w3c-dist-auth@w3.org
- Message-ID: <4C77C991.5080700@gmx.de>
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