+1 to what Samit said: I was not proposing requiring (MUST) a single format in the Core Spec. My suggestion was that the Core Spec guide (or require) the Domain Specs to make sure that clients only need to support a single representation for EACH scenario. The language you had proposed used phrases like "OSLC domain specifications are expected to...". I would prefer that this language be made stronger. Steve Speicher suggested using "SHOULD", and I am ok with with Core Spec providing softer guidance to Domain Specs instead of a hard requirement.
Scott Bosworth's point in his response was that all the Domain Specifications are already "requiring" at least one specific representation (currently that representation seems to be RDF/XML). And I agree with him that in practice my concern about clients having to support mulitple formats are indeed unfounded. However, I would much rather prefer that this was clearly reflected in the Core Spec. We can't assume what specification someone would start reading first. Frankly, I would hope that some folks (especially service consumers) who are wanting to get an exposure to the technical direction around OSLC start with the Core Specification. In those cases it would be nice if they immediately got the picture that across OSLC we are focused on service consumers having to do "less work" in order to support exactly the same scenario with mulitiple providers. My goal with this message was just to clarify my point. I am convinced that in practice we are meeting the goal... I just want to make sure that we reflecting that practice in the specification. I do not want to drag this discussion out any further and I am ok with whatever you decide. Andy Berner Lead Architect, ISV Technical Enablement and Strategy IBM Rational Business Development 972 561-6599 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html
