[Oslc-Automation] "application/rdf+xml MUST be returned" (was: Actions 2.0 majority of already passed resolutions for updates based on Ian's feedback)

[John Arwe]

> I presume this is standard wording from the other specs: " If the 
> client does not indicate a preference, application/rdf+xml MUST be 
returned."

Using a sample size of 1 (Automation 2.1), it is not.
I'm not sure when in crept in, but no doubt it was influenced by our 
(likely: my) LDP editing, since the wording is essentially identical.

Looking at Core 2 more deeply, it's debatable that Actions should be 
saying anything about required representation formats.  Core 2 (aside from 
query results, somewhat oddly) has no MUST for RDF/XML that I can find. 
That appears to come in at the domain spec level.  I don't object having 
it where it is; especially given the ultimate intent to move things to 
OASIS as needed, you'll get another crack at it as soon as CM 3.0 drags it 
in, if not sooner.


> But that means at v3 we won't be able to say the same thing about 
> Turtle while also allowing providers to be backwards-compatible to 
> v2. 

What you say is true.  With how I've come to think about specs & how they 
are used over the past few years, I'd say this doesn't matter; it's a 
distraction.  I know, strange.

Providers tend to think about specs as "what I have to do to get the gold 
star" for some purpose ... marketing, at a minimum.
Consumers tend to think about specs as "if I do what it says, I'm not 
locked into any single provider - I'll interoperate with all 'compliant' 
providers"... in other words, they think compliance guarantees 
interoperability.
Trouble is, as soon as the spec has a single 2119 keyword other than 
MUST[NOT] ... and ALL specs do ... you've lost that guarantee.  It's now 
about grey areas again; does the client use the optional features or not, 
is the client coded to degrade gracefully (and will the human users *care* 
that it's graceful, or just say "not interested"), and so on.

So in the end it's up to social systems to get interop where it exists - 
by which I mean the aggregate answers to "do people buy X" and "do people 
use Y (free stuff)".  The best specs can do is stay out of the way, which 
might well lead us to remove the "LDP clause" you cited above.  I'd be 
fine doing that.



> I guess we just won't state what the default is at v3 (or say it
> MUST be one of RDF/XML or Turtle). John (& Steve) Is that what you 
> would expect v3 to say? 

[1] shows how OSLC tries to solve those problems.
Unless server implementations require the header always (I've never seen a 
single one that even checked, but different problem), and clients always 
send it (I'll bet most don't), you're outside the interop regime anyway.


[1] 
http://open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning

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/20140915/fc23479e/attachment-0003.html>