[oslc-scm] One more change to closure syntax

Nick Crossley ncrossley at us.ibm.com
Fri Aug 6 11:03:30 EDT 2010


After discussion with other OSLC work group leaders, we have decided that 
we want to reserve the '+' operator for its traditional meaning of 'one or 
more' rather than reuse it to mean 'zero or more up to some domain 
specific limit', as was proposed for use in the SCM spec.  Similarly, if 
this closure syntax is adopted in future versions of the core spec, the 
'?' operator would have its conventional meaning of 'zero or one', and '*' 
would mean 'zero or more'.  Both the '+' and '*' closures would have no 
upper limit.

To meet the needs of SCM, and potentially other domains,  we need a new 
symbol to mean a partial closure with some depth limit, and we have agreed 
to use the '!' symbol.  While SCM 1.0 needs only one meaning for a partial 
closure, namely recursion through the member property down to a component 
boundary, the syntax will allow multiple occurrences of the '!' operator 
to mean increasing depths of recursion.

At the same time, we have moved the placement of the closure operator from 
the end of the nested property syntax to immediately after the name of the 
link property - for example 'foo*{bar}' rather than our previously 
proposed 'foo{bar}*'.

Note that the OSLC core specification permits clients to request 
properties that might or might not exist on a particular resource; the 
response will include the requested properties if and only if they exist. 
So effectively, all requests for properties have an implicit '?' operator 
at the end.

Thus in a provider implementing the full future syntax:

foo{bar} would match nothing, or just foo if that property exists but is 
not a resource with a bar property, or foo and foo.bar if the foo property 
exists and is a link to a resource with a bar property
foo?{bar} matches nothing, bar, foo, and foo.bar
foo*{bar} matches nothing, bar, foo, foo.bar, foo.foo.bar, 
foo.foo.foo.bar, etc., without limit, 
foo+{bar} matches nothing, foo.bar, foo.foo.bar, foo.foo.foo.bar, etc., 
without limit
foo!{bar} matches nothing, bar, foo.bar, foo.foo.bar, foo.foo.foo.bar, 
etc., up to some domain or provider specified limit or boundary
foo!!{bar} matches nothing, bar, foo.bar, foo.foo.bar, foo.foo.foo.bar, 
etc., up to a deeper domain or provider specified limit or boundary
foo!!!{bar} matches nothing, bar, foo.bar, foo.foo.bar, foo.foo.foo.bar, 
etc., up to an even deeper domain or provider specified limit or boundary

Note that we have not yet defined a syntax for 'one or more up to some 
limit or boundary'.

In SCM 1.0, we do not require all the above.  Matching the previous 
features of the SCM spec, we need only the '*' and '!' operators, not the 
'?' or '+', and we require only one level of '!'.

So for SCM, the syntax oslc.properties=oslc_scm:member!{dcterms:title} 
means you want to retrieve the dcterms:title property from the subject 
resource itself, and from all members recursively down to a component 
boundary.  Similarly, the syntax 
oslc.properties=oslc_scm:member*{dcterms:title} means you want to retrieve 
the dcterms:title property from the subject resource itself, and from all 
members recursively down without limit.

I have updated the SCM spec with this new syntax; again, this is just a 
change of syntax and does not add any new features (other than to clarify 
that the nested properties are fetched form both the linked resources and 
the subject resource in a closure, not just the linked resources).

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-scm_open-services.net/attachments/20100806/cd1e712a/attachment-0003.html>


More information about the Oslc-Scm mailing list