[oslc-core] Encoding of OSLC resources

[John Arwe]

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 at IBMCA
To:     John Arwe/Poughkeepsie/IBM at IBMUS
Cc:     oslc-core at open-services.net, Vivek Garg/Cupertino/IBM at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111207/a56dfebf/attachment-0003.html>