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

[Arthur Ryman]

Andy/Samit,

I think the current wording is OK because the specifications that OSLC is 
publishing are open and voluntary. People will adopt them because they 
find it beneficial to do so, not because OSLC enforces compliance, or even 
certifies compliance. For any given specification, the service providers 
will provide the formats that they believe will reach the largest 
audience. This will attract a set of clients to support those formats. 
This in turn will motivate new service providers to support those formats 
so they can work with those clients. That is how standards become widely 
adopted.

Today it appears that RDF/XML has the greatest uptake. Therefore, service 
providers will support it. However, we know that there are arguably better 
formats for RDF, e.g. Turtle, and those may become popular in the future. 
I remember when XML was the preferred format for sending data to Web 
browsers. Then JSON took over that role. Maybe a future wave of Web 
browsers will have native Turtle support and RDF graphs will be included 
in the DOM.

If OSLC service providers support RDF/XML, then it will become the de 
facto standard. Today, not all implementations will use RDF toolkits. I 
expect services to upgrade to RDF toolkits in future releases, in which 
case they will be able to easily generate any RDF format. Maybe a standard 
for RDF/JSON will appear. Then browsers will be able to indicate their 
preferences and get potential performance improvements from services that 
support multiple RDF formats.

So in practice, RDF/XML will be the lingua franca, but better formats 
could take over in the future.

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube







From:
Andrew J Berner <ajberner at us.ibm.com>
To:
Dave <snoopdave at gmail.com>
Cc:
oslc-core <oslc-core at open-services.net>
Date:
07/26/2010 10:47 AM
Subject:
Re: [oslc-core] "One last" change to OSLC Core representations
Sent by:
oslc-core-bounces at open-services.net




Dave wrote:


Having a "firm requirement for at least one representation" does help
clients, but we are not there today in our implementations. Today,
OSLC implementations have and will continue to have for some time
limitations in their abilities to provide and accept RDF/XML. Changing
to SHOULD acknowledges fact and still points the way forward.

The term SHOULD is actually a pretty strong requirement, here's what it
means:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.


Dave--for the implmentations that don't provide/accecpt RDF/XML, what's 
the
"valid reason in particular circumstances to ignore" the requirement other
than "they don't".  "Should" shouldn't mean "you have to do it, unless you
don't do it, in which case you don't have to."

I second Samit's concern that unless there is a representation used by all
providers, a client writing code would then have to write separate code 
for
each provider, which they could do without OSLC by using the native api of
the provider.

I used to teach a mathematics class for elementary school teachers that 
was
required for graduation.  When a second semester senior failed the course
(for no good reason other than not studying), I was asked to waive the
requirement, because otherwise he couldn't graduate.  I didn't, by the 
way.


Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html


_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net