[oslc-core] Encoding of OSLC resources

[Steve K Speicher]

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