[Oslc-Automation] Availability Spec review - my feedback - OSLC Actions - thread 1 general comments

[John Arwe]

[off topic gripe]  Oy, this kind of thing is why we need a real comment 
tracking system.  Splitting into several smaller threads based on (and 
trackable in the archives via) unique subject.

"page only available to wg members" is fixed.  I also asked the webmaster 
to update that message when he gets a chance by adding instructions/ptr to 
same on how to actually make the change.  I had to retrieve that bit of 
memory from drum, and the submitters probably never had it to retrieve.

reminder to all: don't rely too heavily on formatting in emails to 
communicate your point.  Anyone looking at the web archives won't see 
formatting.

> I expect John would suggest "oslc-availability" for the standard prefix, 
but oslc_avail is more consistent with Automation 2. I don't mind either 
way. 

I never lay in the tracks over choices like this.
I tend to like the long form in the specs and examples *only* because it 
makes things more self-defining to new readers, and I hate underscores 
(requires coordination to hit 2 keys with opposite hands).  On the wire I 
don't think it matters; most production services would use a gzip transfer 
encoding anyway, and both zip well.  Plus implementations can always 
choose their own prefix binding.

> "It is recommended that any additional properties exist in their own 
unique namespace ... A few paragraphs down we make it a SHOULD - I guess 
that's the same as "recommended" in prose).

As our Terminology section already says, RECOMMENDED (in caps) is already 
a 2119 keyword, and 2119 equates it to SHOULD.  So just uppercase the 
first, decide whether or not you need to say it 2x (if not choose one and 
nuke), done.

> I would suggest something longer in the namespace URI though, perhaps: 
http://open-services.net/ns/availability# 

+1

> Please create a vocab document (or a wiki page to use as a draft) to 
define each of these terms outside the conext of these particular resource 
tables.

You might want to take advantage of a spec authoring tool we have queued 
up internally for submission to Eclipse Lyo.  Today it translates between 
wiki markup and OSLC resource shapes.  It would be easy enough to extend 
it to take a set of shapes and generate a skeleton vocabulary document. 
There's a small Core vocabulary extension to handle the common "X is 
usually a Y" boilerplate, too.  I'm not sure where it is in the 
contribution process, but I can give you an internal contact.

> John: What does "read-only" technically mean here? The most important 
question here for this version is: would changing the read-only flag for a 
property in a subsequent version cause any problems? And is a provider 
non-compliant if they allow it to be written? If not, I'm happy to leave 
it, as it can always be changed if anyone raises a scenario for those 
cases. 

Based on (extensive and spirited) discussions a year or two ago in Core 
where I poked at exactly that kind of question, I believe the consensus 
was that the resource shapes (resource tables are equivalent expressively, 
just in wiki markup syntax) set expectations ( <- the Key Word) for 
interoperability, but do not equate to compliance requirements (indeed, 
the term 'compliance' is undefined in the context of OSLC, for anyone who 
wants to invoke formal logic).  One reason is that scenarios commonly need 
and expect different values based on the method, not just the resource. 
Write-once values often can be set only on the POST to create, for 
example.  Yet the specs don't have separate tables for create vs 
later-update; they're assuming the normal case (update, since you can only 
create something once) and assuming that the values for other cases 
(create) might be different.

> why the link is pointing in this direction, and not from the group to 
the members? ... If we require looking up of reverse links, 

Don't infer which triples the server serves from the tables alone.  Using 
the memberOf pattern we have here, GET against the group can still serve 
the memberOf triples (whose object, not subject, URI is the group's URI); 
the members can ALSO serve those triples if they like; there might be one 
backing store, or two; as an interface, you shouldn't be able to know and 
shouldn't care.  As long as you keep that in mind, it makes a lot less 
difference which direction they "appear" to point.  There are valid 
trust/provenance issues if the collection and members are served by 
different servers (as in: server A is telling me that server B.member2 
says it's a member of A.groupZ ), but unless that's expected to be the 
case here they're no worse than in any other spec.

So this is, in the end, best answered simply in terms of the scenarios. If 
there is a clear winner in terms of which "direction" things are likely to 
happen, makes sense to use that in the tables.  If not, it's nothing to 
agonize over because of the RDF flexibility ... you could even put them in 
both tables, if shapes were well-defined for that case, but they're not so 
today the best alternative is text following the "losing" table where 
they're absent.


> John: Can range be used like this? 

I think you're referring to the ">=0" range.  Short answer, no, that goes 
in the description or normative text.  As a general comment, any time the 
type is other than resource, the representation and range values must be 
N/A.  I think the wiki/shape tool would catch this and complain, btw.  I 
know most people have not memorized the valid column combinations (a close 
look at almost any of the 2.0 specs proves that!), so I know I have code 
somewhere that checks it... and I'd bet that said code was fed into the 
authoring tools contribution mentioned earlier.  While I'm capable of 
committing that kind of fussiness to memory given sufficient practice, I 
consider that valuable real estate best used for other things.

> Should this [X] be an rdfs:subClassOf Y ... I think we can always add 
subClassOf in future, but removing it would be harder

Recall that OSLC Core WG has explicitly chosen to actively DIScourage any 
requirement for clients to support inferencing.  They/we've not, to my 
knowledge, enshrined that as a MUST NOT in any spec, although IIRC I've 
raised that as a "why not?"  In the vocabulary document, I suspect we 
could go either way.  It does mean however that, in a serialization of the 
resource, one should always (if we did subclass things) find at least two 
type URIs, X and Y... that's how you avoid the subclassing creating an 
implicit requirement for clients to inference.

> why is it "often" an AG

FYI, in my copy of the PDF (uploaded April 23 according to the wiki) the 
word "often" never appears, so I wasn't able to connect that to any 
specific case/location.

> You don't have any text about ...how the client can change the condition 
of an availablity resource.

I assume you're after content analogous to Automation 2.0 "how a client 
can cancel a request".  That seems appropriate.






Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140514/41952126/attachment-0003.html>