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 <[email protected]> wrote on 06/14/2010 11:50:33 AM: > From: Dave <[email protected]> > To: [email protected] > Date: 06/14/2010 11:50 AM > Subject: Re: [oslc-core] PREFIX dc: <http://purl.org/dc/elements/1.1/> > Sent by: [email protected] > > 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 <[email protected]> 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 | [email protected] | > > 919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f) > > > > _______________________________________________ > > Oslc-Core mailing list > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
