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-boun...@open-services.net> wrote on 09/15/2014 10:58:04 AM: > From: Martin P Pain <martinp...@uk.ibm.com> > To: John Arwe/Poughkeepsie/IBM@IBMUS > Cc: oslc-automation@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-boun...@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-boun...@open-services.net> wrote on 15/ > 09/2014 15:34:15: > > > From: John Arwe <johna...@us.ibm.com> > > To: oslc-automation@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-boun...@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@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@open-services.net > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
