Some initial feedback/thoughts below. Can discuss more at tomorrow's meeting.
> From: Dave <[email protected]> > To: oslc-core <[email protected]> > Date: 07/20/2010 09:13 AM > Subject: [oslc-core] OSLC representations change proposal > Sent by: [email protected] > > Following the discussion at the OSLC Core workgroup meeting last week, > I've been thinking about how the core should best handle statements > about representation formats. Up until now, we've been requiring > RDF/XML and specifying a specific constrained form of RDF/XML. > Additionally, we stated that other representation formats may be > supported or required by domain specs and product implementations. > Some of the reasons we did that were to stay in-line with existing > OSLC implementations, to make the RDF/XML more consistent and easier > to handle with XML tools and to give guidance to those attempting to > generate RDF/XML without the benefit of an RDF toolkit. > > Several people suggested that it was unwise to put constraints on > what was is deemed a valid RDF/XML format and attempt to specify an > RDF/XML subset, essentially a new format that will require much better > specifications, conformance tests, etc. Instead, they argue that we > should stick with plain-old RDF/XML, recognizing that particular > implementations may have temporary constraints that will be worked out > as they improve their RDF infrastructure over time. Agree > I agree with those suggestions and have a proposal to mandate RDF/XML > and allow other formats, but remove any suggestion to offer a subset > of RDF/XML from the Core spec entirely. Here's a summary of the > changes I propose: > > 1) Change the OSLC Core spec to say: > > OSLC services MUST provide RDF/XML and MAY provide other formats such > as Turtle and JSON. OSLC clients can not assume any specific subset or > form of RDF/XML, such as Abbreviated RDF/XML. What is "Abbreviated RDF/XML"? I can't find any concrete definition of this. Perhaps we can just remove reference of it. > For HTTP POST and PUT operations, OSLC services SHOULD accept RDF/XML > content and MAY accept other representations. OSLC domain > specifications should specify which formats are required and which, if > any, are optional. Agree. > 2) We remove the step-by-step instructions for generating RDF/XML, > JSON and Atom from the Core spec because they are not well specified > or widely implemented enough to be in the final OSLC Core > specification. Agree for RDF/XML. For JSON and Atom, I believe an algorithm/approach/guidance is still needed since there are no well-defined or industry standards to use. > 3) There is no longer a need for a separate section for each > representation format that we allow so remove those sections. Replace > them with some text at the start of the OSLC Representations section > and mention only RDF/XML, Turtle and JSON. Agree. > 4) Create a new OSLC Core Representation Guidance document that tells > people: use an RDF toolkit to generate your representations and if you > don't have a toolkit, then here are some step-by-step instructions for > going from OSLC defined resources to valid RDF/XML, JSON and Atom > representations. Agree. > I'd like to discuss this at tomorrow's workgroup meeting so please > review, and if you have time give some feedback. > > Thanks, > Dave > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
