(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 [email protected] wrote on 05/09/2012 10:32:02 PM: > From: Charles Rankin/Austin/IBM@IBMUS > To: [email protected] > Date: 05/09/2012 10:32 PM > Subject: Re: [Oslc-Automation] Potential new requirement > Sent by: [email protected] > > 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
