Subject: Re: Data Model

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Sep 2010 18:35:08 +0200

On 30.08.2010 20:08, David Nuescheler wrote:
> Hi Julian,
>
> thanks for the additional color.
>
> Let me chime in on one aspect...
>
>>> 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?
>
> Well, personally, I would rather avoid that route.
>
> I thought about this from various different aspects and while it of
> course works from an implementation and usage standpoint I would argue
> that it sets the wrong expectation and targets the wrong use cases.
>
> In my mind the general case is that the "nodes" (or the lack of a
> better term) do not have a "binary stream" associated, and in
> exceptional cases they do. I see the fine-grained nature more similar
> to rows of a table in relational database.
> So in my mind it is important to identify the "binary content" as the
> special case and make sure that the "binary content-less" concept is
> treated as the general case, and not the other way around.
>
> I realize that this is just a matter of setting the perception
> correctly but that's precisely why would like to be careful ;)
> ...

Understood.

I think once we have defined addressing we'll have to get back to this 
question -- if a node gets a URI we'll have to answer what its GETtable 
representation will be...

Best regards, Julian

---

From: David Nuescheler <[email-masked]>
Date: Wed, 8 Sep 2010 15:57:16 +0200

> If ordering of collection members is relevant, then mapping to a Javascript
> array (instead of object) is probably required:
sigh... i know... unfortunately...

regards,
david

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Sep 2010 15:55:48 +0200

On 29.08.2010 21:05, David Nuescheler wrote:
> ...
>> 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...)
> ...

If ordering of collection members is relevant, then mapping to a 
Javascript array (instead of object) is probably required:

    An object is an unordered collection of zero or more name/value
    pairs, where a name is a string and a value is a string, number,
    boolean, null, object, or array.

(<http://tools.ietf.org/html/rfc4627#section-1>)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Sep 2010 17:17:40 +0200

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

---

From: Justin Edelson <[email-masked]>
Date: Wed, 8 Sep 2010 11:19:51 -0400

> sigh... i know... unfortunately...

Too bad this results in overly verbose data structures and annoyingly
complex iteration code.

Justin

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Sep 2010 17:35:32 +0200

> more feedback appreciated.

Related to naming of resources and properties we *also* have to think 
about whether they should share the same space of names.

In WebDAV, properties are not exposed as HTTP resources (*), instead the 
special HTTP method PROPFIND is used. Thus, collisions between 
properties and children of a resource are no concern: a folder could 
have both a child resource "foobar" and a property "foobar".

(*) Yes, that's one of the big issues with the WebDAV approach; but 
maybe we can fix this by exposing WebDAV properties over HTTP GET in the 
future.

In JCR, the same space of names is used for resources and properties, 
thus once the name of a child resource and a property collide, it 
depends on the type of API which one you'll get. This is something we 
need to avoid.

[[ Note: XPath uses a path-like syntax to address both elements and 
attributes, but easily works around this because @ is not valid in 
element names; similarly, it takes advantage of other reserved 
characters such as "(" and ")" to disambiguate between function and 
element names ]]

In David's JSOP slides, we see examples similar to:

var collection1 = {

   "createdby" : "user1",

   "child1" : {

     "createdby" : "user2"

   },

   "child2" : {

     "createdby" : "user3"

   }
};

That has the same problem as JCR; member names and property names can 
collide.

I think we'll need to disambiguate by introducing intermediary objects 
such as "props" and "members", or even model the collection containment 
using a reserved property name.

Best regards, Julian

---

From: Mike Douglass <[email-masked]>
Date: Mon, 20 Sep 2010 11:54:07 -0400

In CalWS

http://www.calconnect.org/pubdocs/CD1011%20CalWS-Rest%20Restful%20Web%20Services%20Protocol%20for%20Calendaring%20V1.0.pdf

we exposed properties and relations using XRD

http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html

which allows a GET with using ACCEPT to specify the xrd object

There's currently no way to specify which properties are desired.

> In WebDAV, properties are not exposed as HTTP resources (*), instead 
> the special HTTP method PROPFIND is used. Thus, collisions between 
> maybe we can fix this by exposing WebDAV properties over HTTP GET in 
> the future.
>
> such as "props" and "members", or even model the collection 
> containment using a reserved property name.
>
> Best regards, Julian
>
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Sep 2010 18:38:50 +0200

On 20.09.2010 17:54, Mike Douglass wrote:
> ....

Content negotiation to get the metadata instead of the data?

Not sure this is a good idea...

Best regards, Julian

---

From: David Nuescheler <[email-masked]>
Date: Thu, 23 Sep 2010 19:42:17 +0200

Hi Julian,

> Related to naming of resources and properties we *also* have to think about
> whether they should share the same space of names.
I would vote for sharing the same space, since it makes it more
compatible and in my experience it really adds complexity having two
namespaces.

> special HTTP method PROPFIND is used. Thus, collisions between properties
> and children of a resource are no concern: a folder could have both a child
> resource "foobar" and a property "foobar".
> (*) Yes, that's one of the big issues with the WebDAV approach; but maybe we
> can fix this by exposing WebDAV properties over HTTP GET in the future.
> In JCR, the same space of names is used for resources and properties, thus
> once the name of a child resource and a property collide, it depends on the
> type of API which one you'll get. This is something we need to avoid.
Agreed. As a historical comment, I think we ended up in the situation
with JCR since XML also has separate name spaces for elements and
attributes and we offer a round tripping of XML into JCR and back.

> attributes, but easily works around this because @ is not valid in element
> names; similarly, it takes advantage of other reserved characters such as
> "(" and ")" to disambiguate between function and element names ]]
I would argue that this is not a problem but a feature. As much as in
a filesystem files and folders share the same namespace it one should
apply the same to properties and resources. More importantly as you
indicate the JSON limitation would suggest a single namespace as well.

> I think we'll need to disambiguate by introducing intermediary objects such
> as "props" and "members", or even model the collection containment using a
> reserved property name.
Since I see simplicity as one of the main reasons to do this effort I
would rather not complicate the simple case where we don't have a
collision just because there might be a chance of an edge. Especially
since I don't think there is any real value in the additional
flexibility that would allow "same named" properties and resources.

regards,
david