[Oslc-Automation] Potential new requirement

[John Arwe]

(Obligatory Monty Python quote: "I'd like to answer that question two 
ways, first in my normal voice, and then in a kind of silly, high-pitched 
whine.")

There at least two tacks one can take on most of those questions (i.e. 
those except the one on existing guidance).  It comes down to one's 
definition of "correctness" - is it adherence to exactly what is written 
(letter of the law) or the authors' intent (spirit of the law)?

1: "Spec lawyer" approach, i.e. narrowly read as literally as possible.
In such a reading, occurrence constraints other than 0 and 1 let an 
implementation do pretty much anything it wants.
Even allowing 0 opens a similar door (impl has 1 value, chooses to expose 
0, still compliant according to the resource definition alone).
Narrowing the range of potential interpretations often helps adopters 
(simpler code on both sides), but also narrows the scope of applicability 
of the spec.
Narrow it too much and it's not useful for wide adoption.
Failing to consider *all* cases up front often results in an overly narrow 
spec.
Narrowing it by covering all the edge/corner cases makes the spec harder 
to understand, therefore harder to implement as the authors intended.
Widening an existing spec is usually incompatible for existing clients, 
which makes them less likely to adopt the new version.
Since no (widely useful) spec is free from conditional requirements (MAY, 
SHOULD), compliance != interop, at least not guaranteed interop.
Where the letter of the spec makes it hard for an implementation to meet 
some point, they'll find a way around the letter of the spec.
You can't legislate (MUST) good behavior.

2: "principle of least surprise" approach, i.e. do what users expect.
This is less prescriptive than the first approach, because expectations 
vary by audience.
To the degree it achieves its stated goal, it would arguably result in 
better (more widespread) adoption.
In the extreme case, one could argue that the set of common expectations 
held by each sub-audience in effect creates a new spec (variant), and 
interop is likely only within a sub-audience.

Adoption is many people's yardstick for the success of a spec... and for 
implementations.

Let's examine just one point along both lines
> if such a property is available within the underlying implementation, 
the service provider will give it to me.
A spec lawyer would find that easy to fix; just add a MUST (if impl has 
it, must expose it).
Then you'll find out that 

1: some implementations will "naturally have it lying around".  Others 
will have to calculate it, perhaps across a distributed system of many 
nodes, i.e. the calculation is expensive.  Do the calculators "have" it, 
so they are subject to the if-clause whose consequence is the MUST, or 
not?  Spec lawyers can add more text to cover that; and unless that new 
text is a MUST, you've not actually narrowed the spec you've just added to 
its size and complexity.

2: some implementations will implement granular access control.  User A 
has read permission on the property (or even on some property values, aka 
RDF triple objects), User B does not.  Both GET the same resource.  The 
"if impl has it, must expose it" solution (if already finalized) means 
this implementation CANNOT be compliant; changing the finalized version 
(editing the if-clause to take this new case into account) MAY break 
existing clients (certainly in the general case; perhaps not in this 
particular case).

The POLS approach would be to hang a SHOULD on it (if impl has it, should 
expose it) or just remain silent.  Since it's conditional, yeah a provider 
can do (or at least appear to do) pretty much whatever it wants and still 
be "compliant" according to the spec lawyers.  It allows provider 
implementations to make decisions based on their audiences, and their 
consumers (broadly speaking, "the market") decides if those decisions were 
"good enough" overall.  While it technically (spec lawyer reading) allows 
those decisions to be coin-flips (random), the market of clients probably 
will not tolerate that well... code (coders) prefer predictability.


The spec lawyer approach also tends to have trouble coping with unbounded 
values.  Take the "0:*" case ... read literally, a spec lawyer could 
easily argue that a compliant server implementation MUST be able to store 
an infinite number of triples (per subject) using that predicate - which 
is clearly nonsense in the real world.  It says that NO provider 
implementation is or can be compliant.  The only real-world-reasonable 
interpretation of that I can craft is that implementers have to be able to 
cope with >1, and each will have an implementation-defined upper limit.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario


oslc-automation-bounces at open-services.net wrote on 05/09/2012 10:32:02 PM:

> From: Charles Rankin/Austin/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 05/09/2012 10:32 PM
> Subject: Re: [Oslc-Automation] Potential new requirement
> Sent by: oslc-automation-bounces at open-services.net
> 
> I'm intrigued by the suggestion of using zero-or-one as an "opt-in".
> My interpretation of this as a consumer would have been, if such a 
> property is available within the underlying implementation, the 
> service provider will give it to me.  Thus, if it isn't present, no 
> such property exists in the underlying implementation.  However an 
> "opt-in" interpretation says that it may very well exist, but the 
> service provider is simply choosing not to give it to me.  Is there 
> any guidance (in Core) around this?  Does this behavior have to be 
> deterministic in any way, or can the provider "randomly" choose when
> it wants to provide the property? 
> 
> Is this type of opt-in behavior valid for zero-or-many properties? 
> For example, can an Automation provider arbitrarily choose not to 
> include the oslc_auto:input Parameters for an AutomationResult 
> resource definition even when it is otherwise capable of doing so? 
> 
> Charles Rankin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120510/36d5bdb8/attachment-0003.html>