[oslc-core] Encoding of OSLC resources

[Frank Budinsky]

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.


                                                                                                                           
  From:       John Arwe/Poughkeepsie/IBM at IBMUS                                                                             
                                                                                                                           
  To:         Frank Budinsky <frankb at ca.ibm.com>                                                                           
                                                                                                                           
  Cc:         oslc-core at open-services.net                                                                                  
                                                                                                                           
  Date:       11/30/2011 03:55 PM                                                                                          
                                                                                                                           
  Subject:    Re: [oslc-core] Encoding of OSLC resources                                                                   
                                                                                                                           





> 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/85a1a478/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111130/85a1a478/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111130/85a1a478/attachment-0001.gif>