> I'm still not seeing how the various recommendations and strong recommendations provide any guarantees for the client.
I suspect the loop-holey-sounding words in a place or two + not reading the originals that they summarize may be getting you. Or we are not yet sufficiently precise on the question or some other assumption. My RDF/XML reasoning: OSLC Core 2.0: producers MUST support application/rdf+xml RFC 3023 application/rdf+xml: charset optional - If charset used: UTF-8/16 [weasel words]. If you drill into [XML 4.3.3], MUST on both for conforming XML processors (then you have to visit [XML 5] to be sure you like that definition) - If charset omitted: [XML 4.3.3] governs; *it* says the charset is either taken from the document declaration, BOM, or must be UTF-8. But as above, processors are only required to support 8/16. Depending upon your actual question/requirement, that may/not be sufficient. If your question is "is there any particular encoding(s) that a client can use in its request and know that all OSLC producers could process the request (as least as far as encoding is concerned)?" then the above seems to answer either UTF 8/16. If your question is "is there any particular encoding(s) that a client can explicitly request in its response and know (iron clad guarantee) that all OSLC producers could comply with the request?" then the above seems to answer either UTF 8/16 (but note I wrote "Could" not "Would"). In the interests of fair disclosure, I cannot guarantee that your client will always receive such a response since Accept-* headers in general are *hints* to the server not constraints on its behavior, per HTTP RFC 2616. All the above guarantees is that your client will be able to reliably determine what encoding the response uses, regardless of the presence/absence of Content-Encoding in the server's response; it does NOT guarantee a non-zero intersection between the set of encodings your client understands and those the server sends. If it is your goal have such a guarantee then we do need more (or we need to accept the Web as it is). Since the 3023 rules work both ways (what's good for the goose is good for the gander time), it will be "in the best interests" of producers to respond with UTF 8/16 (especially in the absence of an Accept-* indicating some other preference), but that is certainly not an iron-clad guarantee. If your question is "is there any particular encoding(s) that a client must be able to understand in order to process any response from any producer" then the above seems to answer either UTF 8/16 as your starting point, but again (because of HTTP) there no guarantee that the server sends either, ever (AFAIK) in HTTP, as stated above. RDF/JSON et al. would each require a similar analysis. But before going there I'd like to clarify the question(s) first. While constructing the above is fun to a degree, it's neither fast nor easy to get right. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
