[oslc-core] Core Issue 43 : "read only and friends" - number of value types

[John Arwe]

Per my action from last week, I've started to draft clarifying changes for 
the subject issue [1].  In comparing the text in Core (defining resources) 
[2] and Core Appendix A (resource shapes) [3] I've run into some new cases 
that we have not discussed in [4] or [5] or IIRC the calls, so the 
original intent is unclear.  I'd like to get some feedback on that, with 
the hope of consensus emerging that I can work into the draft before 
posting it.  To make the threading help as much as possible, I'll be good 
and keep it to one issue per thread.

This thread: Core resource definitions allow >1 value type, but resource 
shapes permit only 1.

The answer here will also influence Steve's work on [6].


[2] says "Value-types: A property MAY allow multiple value-types and a 
value MUST satisfy one of them. Each value-type MUST be a URI that 
corresponds to one of the following: ..."

[3] says oslc:valueType         exactly-one 

[3] also says "OSLC implementations that provide Resource Shapes 
representing resources defined by OSLC specifications SHOULD provide the 
very same information provided in the specifications without changing or 
removing any of the Properties specified. Resource Shapes MAY include new 
implementation specific properties ..."


Do we have any existing specs that explicitly list >1 value type in the 
resource definition tables?  While that answer need not determine how this 
issue is resolved, it would be useful information when evaluating options. 
 Steve appeared to assume in [6] that only one value-type was permitted, 
which matches all my experiences and conversations but that is hardly 
exhaustive.

Based on the "exactly-one" occurs constraint, if a spec allows >1, then I 
see how an implementation would actually implement that - the query 
capability and creation factory -  each allow 0:* shapes.  It would have 
to expose one shape instance per value type.  If multiple properties in a 
single resource follow this pattern, I need to expose a shape for each 
permutation (yikes).

Assuming that allowing >1 value type in a resource definition is required 
(currently in use, or something we're dead convinced we need for the 
future), the question becomes what constraints does that resource 
definition impose on implementations. 
For concreteness, assume the value type list = { String, Resource }. 
Does that normatively require my implementation (provider and/or client) 
to support 
... both String values AND Resource values?
... AT LEAST ONE of String values OR (boolean OR) Resource values?




[1] http://open-services.net/bin/view/Main/OslcCoreV2Issues
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource
[4] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001288.html
[5] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-May/001314.html
[6] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-May/001317.html

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120523/4fe223f6/attachment-0003.html>