[oslc-core] "One last" change to OSLC Core representations

[Samit Mehta]

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:samit.mehta at us.ibm.com
IBM Rational Software - Business Development

oslc-core-bounces at open-services.net 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
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net