[oslc-core] PREFIX dc: <http://purl.org/dc/elements/1.1/>

[Steve K Speicher]

Agreed as Dave, Arthur and I talked through this last week. 

Other area of potential breakage would have been usage as a URL query 
parameters, which doesn't have ability to define prefixes.  Since CM 1.0 
has different query parameter names, oslc.properties vs. 
oslc_cm.properties, then there is no real breakage.

We should do the right thing and use dcterms.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


Dave <snoopdave at gmail.com> wrote on 06/14/2010 11:50:33 AM:

> From: Dave <snoopdave at gmail.com>
> To: oslc-core at open-services.net
> Date: 06/14/2010 11:50 AM
> Subject: Re: [oslc-core] PREFIX dc: <http://purl.org/dc/elements/1.1/>
> Sent by: oslc-core-bounces at open-services.net
> 
> The reason that I was worried about breakage is because we specified a
> JSON format in OSLC-CM v1 spec but we did not specify how to declare
> prefixes. So, old clients will use and expect "dc" and not "dcterms"
> and they'll have no prefix declarations to help them sort things out.
> 
> I now believe that we will not see this breakage because we have a
> spec-versioning story. Old clients won't send the OSLC Core v2 header
> and therefore will never be expected to send or receive the new JSON
> format (with the new dcterms prefix).
> 
> Are there other areas of potential breakage?
> 
> If not, I think we can do the right thing and use dcterms.
> 
> Thanks,
> - Dave
> 
> 
> 
> On Mon, Jun 14, 2010 at 11:40 AM, Scott Bosworth <bosworth at us.ibm.com> 
wrote:
> >>
> >> Arthur Ryman
> >
> >>
> >> <rant>
> >>
> >> As I read more and more external specs, I see a very clear convention 
for
> >> the meaning the prefix dc:. The conventional use is for the elements
> >> namespace, not the terms namespace. dcterms: is used for the terms
> >> namespace.
> >>
> >> I have heard it asserted that if we align with the conventional use, 
then
> >> we might somehow break existing clients, but I haven't see any actual
> >> examples. I believe that it is better in the long term for  OSLC to 
align
> >> with the norms of the larger Web community. We should therefore not
> >> diverge on the grounds of being "bug compatible" with some early
> >> implementations. Let's examine the real breakage, if any, and 
gracefully
> >> deprecate the old usage. Going forward, new specs should align with 
the
> >> convention.
> >>
> >> </rant>
> >>
> >
> > +1
> >
> > How do we get a good understanding of "real breakage"?
> >
> >
> > Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com |
> > 919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
> >
> > _______________________________________________
> > Oslc-Core mailing list
> > Oslc-Core at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> >
> >
> 
> _______________________________________________
> 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/20100614/cd3e60da/attachment-0003.html>