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

[Martin P Pain]

For simplicity (to "stay out of the way") I suggest we remove the "does 
not indicate a preference" sentence. Probably leave the MUST on having 
RDF/XML as one of the options, as I don't believe it does any harm, and 
helps with clients' expectations (both setting them and fulfilling them).

Martin


"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
15/09/2014 15:34:15:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net
> Date: 15/09/2014 15:35
> Subject: Re: [Oslc-Automation] "application/rdf+xml MUST be 
> returned" (was: Actions 2.0 majority of already passed resolutions 
> for updates based on Ian's feedback)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > I presume this is standard wording from the other specs: " If the 
> > client does not indicate a preference, application/rdf+xml MUST 
bereturned."
> 
> 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 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140915/a4b40acf/attachment-0003.html>