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 > >
