So you're after the "...iron clad guarantee...". If the client supports at least one of UTF-8 and UTF-16 and requests an encoding that it understands, it has done all it can do within HTTP. It sounds like the problem from your point of view is that no HTTP client (OSLC or not) technically can force a server to answer in a particular format/encoding (even if the server supports it), using only HTTP. That's a separate issue from the above. OSLC could constrain origin servers' behavior (for OSLC providers), but that either runs counter to the Open World model (OSLC Primer) or only covers a proper subset of possible linked-to resources. To be specific: a constraint on OSLC providers would not help when OSLC resources link to "not OSLC provided" resources; if that's still sufficient for your use cases, then it is a constraint that Core could debate. It appears that HTTP took the approach of tilting the incentives (social solution via the network effect) toward supporting both UTF-8 and UTF-16 for servers serving XML responses rather than requiring it as a matter of compliance. My best guess would be that was intentional to keep very loose coupling. I'd personally be hesitant to take a stronger stance in OSLC unless there are known cases where important data is not available in UTF 8 or 16 *and* we expect that situation to persist indefinitely even in the face of education about all the potential integrations that doing so is giving up on *and* we think a change in stance by OSLC would cause those parties to add UTF 8/16 support. If the latter condition is not satisfied, changing OSLC would not help in the end.
Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Frank Budinsky/Toronto/IBM@IBMCA To: John Arwe/Poughkeepsie/IBM@IBMUS Cc: [email protected], Vivek Garg/Cupertino/IBM@IBMUS Date: 11/30/2011 04:19 PM Subject: Re: [oslc-core] Encoding of OSLC resources Hi John, Thanks for the speedy response. > 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" Yes, that's the question. If the answer to your second question were yes, then that would be the way to solve this one, but since it's no, I think we're stuck with the problem of how can a "complaint OSLC client" know that it's capable of processing the resources from any "compliant OSLC server"? Maybe, as you say, we should just accept the web as it is. Thanks, Frank.
