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

[Steve K Speicher]

I would suggest to remove the MUST on RDF/XML. As I believe with John's 
point, Core typically doesn't enforce a format and domains have the 
restriction.  Though this changes in 3.0 with LDP.  Since this is Actions 
2.0 based on Core 2.0, which doesn't have the MUST, and Automation and/or 
CM will be using Actions, then they can impose the MUST in 2.0 as they do 
already.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net

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

> From: Martin P Pain <martinpain at uk.ibm.com>
> To: John Arwe/Poughkeepsie/IBM at IBMUS
> Cc: oslc-automation at open-services.net
> Date: 09/15/2014 10:58 AM
> 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>
> 
> 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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140915/2334f5d0/attachment-0003.html>