[oslc-core] Oslc-Core Digest, Vol 6, Issue 14
Tack Tong
tacktong at ca.ibm.com
Tue Jul 20 11:18:32 EDT 2010
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
|------------>
| 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
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100720/b20630c0/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/b20630c0/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/b20630c0/attachment-0001.gif>
More information about the Oslc-Core
mailing list