[oslc-core] Encoding of OSLC resources

[John Arwe]

> 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

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