[oslc-core] Oslc-Core Digest, Vol 6, Issue 14

[Dave]

Unfortunately, I don't think we can offer much guidance to client developers
who have no RDF toolkit, except to refer to the RDF/XML specification.

We don't want client developers to hard-code one style of RDF/XML, they have
to be able to handle any form, e.g. both type encoded in element name and
type encoded as rdf:type.

- Dave


On Tue, Jul 20, 2010 at 11:18 AM, Tack Tong <tacktong at ca.ibm.com> wrote:

> Dave,
>
> I won't be able to attend the WG tomorrow. Here is my feedback.
>
> The following focuses for the PROVIDER.
> *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.*
>
> Would you also create a Guidance doc. for the CONSUMER who does not have a
> RDF parser, or a CONSUMER MUST have a RDF parser?
>
>
>
> Tack Tong
> IBM Rational software
> tacktong at ca.ibm.com
> 905-413-3232
> tie line 313-3232
>
> [image: Inactive hide details for oslc-core-request---07/20/2010 10:06:49
> AM---Send Oslc-Core mailing list submissions to oslc-core at op]oslc-core-request---07/20/2010
> 10:06:49 AM---Send Oslc-Core mailing list submissions to
> oslc-core at open-services.net
>
>
> From:
> oslc-core-request at open-services.net
> To:
> oslc-core at open-services.net
> Date:
> 07/20/2010 10:06 AM
> Subject:
> Oslc-Core Digest, Vol 6, Issue 14
> Sent by:
> oslc-core-bounces at open-services.net
> ------------------------------
>
>
>
> Message: 4
> Date: Tue, 20 Jul 2010 09:12:46 -0400
> From: Dave <snoopdave at gmail.com>
> To: oslc-core <oslc-core at open-services.net>
> Subject: [oslc-core] OSLC representations change proposal
> Message-ID:
> <AANLkTilUuiaO88d49o-k53F5CxFxswvEnOR2vd6bwMMv at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
> End of Oslc-Core Digest, Vol 6, Issue 14
> ****************************************
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100720/6672df92/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100720/6672df92/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100720/6672df92/attachment-0001.gif>