headers
Julian Reschke | 1 Sep 2010 18:35
Picon
Picon

Re: Data Model

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Nuescheler | 8 Sep 2010 15:57
Favicon

Re: Data Model

> 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
Permalink | Reply | 1 comment |
headers
Julian Reschke | 8 Sep 2010 15:55
Picon
Picon

Re: Data Model

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
Permalink | Reply | 2 comments |
headers
Julian Reschke | 8 Sep 2010 17:17
Picon
Picon

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)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Justin Edelson | 8 Sep 2010 17:19
Gravatar

Re: Data Model

On Wed, Sep 8, 2010 at 9:57 AM, David Nuescheler <david <at> day.com> wrote:
>> If ordering of collection members is relevant, then mapping to a Javascript
>> array (instead of object) is probably required:
> sigh... i know... unfortunately...

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

Justin

>
> regards,
> david
>
>
Permalink | Reply | 0 comments |
headers
Julian Reschke | 20 Sep 2010 17:35
Picon
Picon

Re: Data Model, as seen from WebDAV

On 08.09.2010 17:17, Julian Reschke wrote:
> ...
>> 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)
> ...
>> 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.
> ...

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,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mike Douglass | 20 Sep 2010 17:54
Picon
Favicon

Re: Data Model, as seen from WebDAV

  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 
> 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  <at>  is not valid in 
> element names; similarly, it takes advantage of other reserved 
> characters such as "(" and ")" to disambiguate between function and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 20 Sep 2010 18:38
Picon
Picon

Re: Data Model, as seen from WebDAV

On 20.09.2010 17:54, Mike Douglass wrote:
> 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.
> ....

Content negotiation to get the metadata instead of the data?

Not sure this is a good idea...

Best regards, Julian
Permalink | Reply | 0 comments |
headers
David Nuescheler | 23 Sep 2010 19:42
Favicon

Re: Data Model, as seen from WebDAV

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.

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

> [[ Note: XPath uses a path-like syntax to address both elements and
> attributes, but easily works around this because  <at>  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"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane