[OASIS Issue Tracker] (ODATA-764) Need clarification of valid character values for Edm.String in relation to ATOM (XML 1.0)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-764:
-----------------------------

    Proposal: 
1. Mention in Protocol spec that some protocols may not be able to encode values for all Unicode characters, or...

2. Recommend using XML 1.1 for Atom (may exclude some clients)

3. Recommend switching to XML 1.1 if content can't be represented as XML 1.0 (puts burden on server)

4. Recommend using Edm.String only for 



3. Determine an approach to encode all valid Unicode characters in ATOM, e.g. encode backspace as:

{U+0009}

(That is, eight separate characters indicating a Unicode HEX value).



  was:
1. Mention in Protocol spec that some protocols may not be able to encode values for all Unicode characters, or...

2. Determine an approach to encode all valid Unicode characters in ATOM, e.g. encode backspace as:

{U+0009}

(That is, eight separate characters indicating a Unicode HEX value).




> Need clarification of valid character values for Edm.String in relation to ATOM (XML 1.0)
> -----------------------------------------------------------------------------------------
>
>                 Key: ODATA-764
>                 URL: https://issues.oasis-open.org/browse/ODATA-764
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ATOM Format, OData Protocol
>    Affects Versions: V4.0_CS02
>            Reporter: Evan Ireland
>             Fix For: V4.0_CSD04
>
>
> OData CSDL spec states that Edm.String is a "Sequence of UTF-8 characters". However some characters (e.g. ASCII control characters < 32 other than tab, newline, carriage return) are not valid in XML 1.0 (all except NUL are valid in XML 1.1 by the way).
> So there are some valid OData String characters not transmittable using ATOM.
> We ran into this recently with a client which was uploading a stack trace (from C#) that was the result of a client side exception (the client was attempting to create a "log record" entity at the server). The client's stack trace text contained a backspace character (which was actually the reason for the client's failure, so therefore it was important content).
> The client successfully uploaded this information to the server (a proxy) using JSON, then the proxy server tried to use XML to further upload that data to a backend server using XML, which failed due to XML 1.0 limitations (backspace not being transmissable).
> This would appear to indicate that ATOM (with XML 1.0) is not suitable for some legal values of type Edm.String. Even with XML 1.1, the NUL character is not transmissable.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)