[oslc-core] Encoding of OSLC resources

Wed Nov 30 10:29:28 EST 2011

I'm still not seeing how the various recommendations and strong
recommendations provide any guarantees for the client. Wouldn't there need
to be a statement that says something like "a server MUST support
charset=UTF-8" ? Otherwise, I'm still not sure I see how an OSLC client can
know for sure what it needs to be able to handle if there is no GUARANTEE
you can request/receive a particular charset. Am I missing some subtle
connection somewhere?

Thanks,
Frank.

  From:       Steve K Speicher <sspeiche at us.ibm.com>                                                                       

  To:         oslc-core at open-services.net                                                                                  

  Date:       11/29/2011 04:38 PM                                                                                          

  Subject:    Re: [oslc-core] Encoding of OSLC resources                                                                   

  Sent by:    oslc-core-bounces at open-services.net                                                                          

I agree with John.  There already seems to be pretty clear language,
pulling up from his [1] reference:

             "utf-8" [RFC2279] and "utf-16" [RFC2781] are the recommended
      values, representing the UTF-8 and UTF-16 charsets, respectively.
      These charsets are preferred since they are supported by all
      conforming processors of [XML].

So answering Frank's original 2 questions:
> 1.        Is an explicit charset required in a response header? If not,
what
> is the default (e.g., UTF-8)?

Based on rfc3023 we can say it is not required and there is a default.  It
may be worth noting that this might be good to call out as it is a) buried
indirectly and b) not likely the rfc will change under us regarding this.
So we could publish some reference to this from the spec or place within
some implementer's guide.

> 2.        What charsets MUST be supported by OSLC resource providers
(e.g.,
> UTF-8 only, or UTF-8 and UTF-16, or other)?

Looks like we have our answer from the quoted text: UTF-8 and UTF-16

Any other thoughts?

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net,
> Date: 11/22/2011 05:23 PM
> Subject: Re: [oslc-core] Encoding of OSLC resources
> Sent by: oslc-core-bounces at open-services.net
>
> Following my nose through the specs (I've done similar before...), I
find
> that (in the specific case cited, i.e. RDF/XML) the governing spec
appears
> to be the media type registration for application/xml and the +xml
suffix
> [1].  Looking at the media type for application/rdf+xml [2], it defers
to
> [1].  [1] has fairly strong recommendations on both charset and
encoding.
> Since OSLC defines its own RDF/JSON serialization, and that re-uses the
JSON
> media type registration in [3], the latter would govern (see section 6,
the
> RFC has no TOC so no direct link).  Again, the reg entry has fairly
strong
> recommendations on both.
> OSLC would theoretically be allowed to specify non-conflicting
requirements
> (or change its media types and do what it likes), however imposing any
new
> MUSTs on existing concepts (especially in Core) would raise
compatibility
> issues.  Do you find the language in the respective media type
registrations
> sufficiently prescriptive for your scenarios?
> [1] http://tools.ietf.org/html/rfc3023#section-3.2
> [2] http://tools.ietf.org/html/rfc3870#section-2
> [3] http://tools.ietf.org/html/rfc4627
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
>
>
>
>
> From:        Frank Budinsky <frankb at ca.ibm.com>
> To:        oslc-core at open-services.net
> Date:        11/21/2011 02:55 PM
> Subject:        [oslc-core] Encoding of OSLC resources
> Sent by:        oslc-core-bounces at open-services.net
>
>
>
> I'm wondering if the OSLC core specification needs to say something
about
> the encoding requirements for OSLC defined resources. Currently it seems
to
> only specify the requirement to support application/rdf+xml content
type,
> but there is no mention of charset. I was assuming that perhaps there
might
> be a well known requirement for the encoding of application/rdf+xml
> documented somewhere else (e.g., in some w3c spec), but I've been unable
to
> find anything concrete. Maybe I just haven't looked long enough?
>
> I think OSLC may need to specify something like:
> 1.        Is an explicit charset required in a response header? If not,
what
> is the default (e.g., UTF-8)?
> 2.        What charsets MUST be supported by OSLC resource providers
(e.g.,
> UTF-8 only, or UTF-8 and UTF-16, or other)?
>
> Thoughts?
>
> Thanks,
> Frank._______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111130/d4189474/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/d4189474/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/d4189474/attachment-0001.gif>