I understand and agree with the sentiment expressed by Samit and echoed by others here, but after having listened in on considerable debate on this question, I don't see a real issue with what is specified in the Core - actually, I think it is clear and astute.
The "truth" on what's required for OSLC implementations is learned by looking at domain specs. The core has set the direction for RDF and has made strong guidance for domain specs while recognizing that there are also other useful representation formats. It's gone even further to recommend RDF/XML, even though other RDF representation formats will ultimately probably be fine, especially given the widespread adoption of open source toolkits like Jena . The domain workgroups have recognized the point offered by Samit and are readily adopting MUST statements re: RDF/XML. I'm not aware of any coming domain specification that is not adopting this stance. And I see no evidence of the problem Tack is suggesting. In practice, this issue is not real even though I could see how it might be in theory. For the Core to unequivocally require a representation for every case, even for those situations it can't predict or yet imagine seems pretty unnecessary and heavy handed (and imho, maybe even a bit foolish). Our attention should be on the domain specs when it comes to this question. We should be especially interested when a domain specification does not follow the core representation guidance (i.e. does not include a MUST for RDF representations). That situation may indicate a scenario that we can learn from or it may indicate arbitrary or unnecessary differences. The spec process allows for and is in place for this kind of debate and decision making. Scott [email protected] wrote on 07/26/2010 12:43:42 PM: > From: Tack Tong <[email protected]> > Core representations > > +1 for me on Andy's comment. > > > 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. > > Tack Tong Scott Bosworth | IBM Rational CTO Team | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f)
