"This shouldn't change anything for provider implementations, but XML-only consumers will need to know to ask for application/xml"
This is not quite true. There was only one format of RDF/XML in Core and it was a MUST. Thus, a consumer can rely on a single common format that every provider would implement. This is important for generic consumers who need to talk to multiple providers. Now, with two formats of RDF/XML, the Core spec. seems to infer that it is up to the Provider to choose which one or both to implement. (At least, that is how I interpret the spec. as I read it.) If this is the case, the only one single format that a consumer can rely on talking to multiple providers would be the FULL RDF/XML. And this requires the consumers to do RDF parsing, and precludes XML consumers. Should we make abbreivated RDF/XML a MUST or at least a SHOULD, so that a generic consumer have a single common format to deal with and it does not preclude XML consumers. Tack Tong IBM Rational software [email protected] 905-413-3232 tie line 313-3232 For those catching up: the basic idea is this: OSLC specs can allow either abbreviated RDF/XML, full RTDF/XML or both forms and use content-negotiation to determine what is returned. This will allow specs to require abbreviated RDF/XML now and later add full RDF/XML without breaking clients. The new spec text describes these three options, how content negotiation works and how to do abbreviated RDF/XML with Jena. This shouldn't change anything for provider implementations, but XML-only consumers will need to know to ask for application/xml or risk breakage later. As always feedback is most welcome. Thanks, - Dave
