Dave, I would recommend stronger language for the following paragraph:
> OSLC domain specifications are expected to (1) require the > representations needed for the specific scenarios that they are > addressing... Maybe something like: "OSLC domain specifications MUST (1) require the representations ..." I do agree with your argument, but I am concerned that it could put a service consumer (client) at a disadvantage if a domain spec ends up without a firm requirement for at least one representation for each scenario. Thanks, ____________________________________________ Samit Mehta (512) 323-9350 - Work mailto:[email protected] IBM Rational Software - Business Development [email protected] wrote on 07/26/2010 07:42:44 AM: > I've got one last change I would like to make before finalization this week. > > We already made changes last week to simplify the section, by removing > the requirement for the abbreviated RDF/XML. As of now we say OSLC > services MUST provide/accept RDF/XML and MAY provide/accept other > formats. > > I'd like to make the Core less prescriptive and more realistic by > changing that MUST to a SHOULD, adding more concise explanation of > intent and removing the 5 paragraphs on "why does OSLC require > RDF/XML". It's less prescriptive because SHOULD is looser than MUST > and it's more realistic because, as far as I know, OSLC > implementations don't yet provide/accept full RDF/XML -- there are > limitations still being worked out. > > Here's the new spec text that I propose: > > > OSLC resource representations come in many forms and are subject to > standard HTTP mechanisms for content negotiation. > > OSLC domain specifications are expected to (1) require the > representations needed for the specific scenarios that they are > addressing and (2) recognize that different representations are > appropriate for different purposes. For example, browser oriented > scenarios might be best addressed by JSON or Atom format > representations. For these reasons, OSLC services MAY provide and > accept standard or emerging standard formats such as XML, JSON, HTML, > Turtle and the Atom Syndication Format. > > OSLC domain specifications are also expected to follow common > practices and conventions that are in concert with existing industry > standards and offer consistency across domains. All of the OSLC > specifications are built upon the standard RDF data model, allowing > OSLC to align with the W3C's Linked Data initiative. In addition, all > OSLC specifications have adopted the convention to illustrate RDF/XML > representations and will typically require RDF/XML representations to > enable consistency across OSLC implementations. > > For those reasons, OSLC services SHOULD provide and accept RDF/XML > representations for each OSLC resource. Though the OSLC Core workgroup > does provide guidance on how to form RDF/XML representations using a > subset of RDF/XML (reference: OSLC Core Representations Guidance) , > OSLC clients SHOULD NOT assume any specific form of RDF/XML. It is > recommended that OSLC services also provide an HTML representation for > each resource. > > > Thanks, > Dave > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
