RE: AW: ACTION-733: Go over exi for json draft and ask the group for review in preparation for publication from Takuki Kamiya on 2016-01-15 (public-exi@w3.org from January 2016)

From: Takuki Kamiya <tkamiya@us.fujitsu.com>
Date: Thu, 14 Jan 2016 20:58:09 -0800
To: "Stephen D. Williams" <sdw@lig.net>, "public-exi@w3.org" <public-exi@w3.org>
Message-ID: <23204FACB677D84EBD57175AB7B5A71C03567577D17C@FMSAMAIL.fmsa.local>
Hi Stephen,

At this time, the WG considers BSON support out of scope.
However, we may revisit it when we see wider demand for BSON support.

We recorded as an issue at [1].

[1] https://www.w3.org/2005/06/tracker/exi/issues/111


Thank you,

Takuki Kamiya
Fujitsu Laboratories of America


From: Stephen D. Williams [mailto:sdw@lig.net]
Sent: Tuesday, January 05, 2016 9:51 AM
To: public-exi@w3.org
Subject: Re: AW: ACTION-733: Go over exi for json draft and ask the group for review in preparation for publication

Handling BSON at the same time as JSON should be considered.  The only additions seem to be binary date and block data types.
http://bsonspec.org/

sdw

On 1/4/16 11:42 PM, Don Brutzman wrote:
Draft is looking good.  Great work Daniel!

Editorial comments:
====================================================================================================
1.  RFC 7159 is not the normative document, rather it is an amplification.  ECMA-404 is normative.  Both references should be provided in this document, please add:

JSON Data Interchange Format, ECMA Standard ECMA-404, first edition, October 2013.
http://www.ecma-international.org/publications/standards/Ecma-404.htm


====================================================================================================
2. Concept

Change
=============================
A number of mappings between JSON structures and XML documents have been proposed. Because none of these mappings is ideal in all circumstances, this specification does not define such a mapping, and instead converts JSON structures to XML event streams.
=============================

to
=============================
A number of general mappings between JSON object structures and XML documents have been proposed. Because none of these mappings is ideal in all circumstances, this specification does not attempt to define such a general mapping.

Rather, the EXI for JSON approach is to equivalently convert any well-formed JSON structures to XML event streams that are directly suitable for datatype-aware EXI compression.  Lossless round-trip conversion back to the original JSON structures is supported.
=============================

Editorial note:
"Do we want to make sure that these EXI options are not overridden?"

I think that this is related to interoperability.  We could be silent about it.  However it is quite conceivable that simple JSON-EXI converters might be written, for example in client-side Javascript, in a browser/server, or even in hardware.  If failure to conform an JSON-EXI stream to the recommended options might break simple converters (i.e. minimalist EXI-JSON converters, not full EXI engines), then we should require the correct values.

Most of the options look simple enough; questions follow.
http://www.w3.org/TR/exi/#exiOptionsInOptionsField


Default EXI Option compression=false which doesn't seem like what we want.

Allowing different/smaller blockSize (default 1,000,000) would allow smaller-footprint implementations

The schemaId should include version information since approach in this document might eventually change.  Thus

- "schema-for-json-1" or, better yet,
- "schema-for-json-1-draft"

Recommendation: require fixed values for options that might affect interoperability among simple JSON-EXI (only) implementations.

====================================================================================================
Sections 3 and 3.2.  Whenever mentioning conversion from EXI to JSON, need to note that the only eligible EXI must conform to the rules of this document.  Am hoping to avoid individuals reading the document from misinterpreting that this is a general approach.

Existing prose:
=============================
JSON data can be converted to EXI.
At the same time, EXI streams, following the rules of this specification, can be converted to JSON.
=============================

Suggested rephrase:
=============================
Any valid JSON data can be converted to equivalent EXI.
Similarly, corresponding EXI streams that conform to the rules and schema of this specification can be converted to equivalent JSON.
This approach is not suitable for arbitrary EXI or XML data.
=============================

Also "on the contrary,"
to   "for equivalent round-trip conversion,"

Also update year and identifier:

Prefix    Namespace Name
j    http://www.w3.org/2015/EXI/json


to use  http://www.w3.org/2016/EXI/json-1-draft


====================================================================================================
3.1 subsections.

Style question:  shouldn't the j: prefix appear in the prose when referring to one of the encoding elements?  For example,

=============================
3.1.2 JSON array
A JSON array is transformed to an array element whose members are the values of the JSON array.
=============================

to

=============================
3.1.2 JSON array
A JSON array is transformed to a j:array element whose members are the values of the JSON array.
=============================

====================================================================================================
d. Typo:
=============================
3.1.4 JSON number

A JSON string MAY be transformed to a number element.
=============================

to

=============================
3.1.4 JSON number

A JSON *number* MAY be transformed to a j:number element.
=============================

====================================================================================================
Please check the html markup for highlighting "numbers" in the following Editorial note:

"The working group considers the xsd:decimal representation for numbers currently at risk..."

Wondering why is this so?  We should explain our concerns so that the feedback might be helpful.

====================================================================================================
Section C.1 phrasing

"The selection of these additional datatypes concluded based on the foreseen efficiency and the use in JSON documents."

to

"The selection of these additional datatypes is based on their foreseen efficiency and potential usage in JSON documents."
====================================================================================================
Section C.2 Character Encoding

=============================
JSON text may be encoded in UTF-8, UTF-16, or UTF-32 (see JSON Character Encoding).
EXI for JSON does not provide any mean to transmit these encodings information.
Processors are recommended to use the default UTF-8 when creating JSON documents.
The preservation of the original JSON character encoding does seem to provide a substantial benefit.
=============================

to

=============================
JSON text may be encoded in UTF-8, UTF-16, or UTF-32 (see JSON Character Encoding).
EXI for JSON matches the JSON specification in that it does not provide an explicit label for the included characters.
If possible without loss of correctness, processors are recommended to use the default UTF-8 for maximum potential compression when creating JSON documents.
=============================

====================================================================================================
Consider adding an Editorial note:

"The working group asks for feedback whether noting the original encoding (UTF-8, UTF-16, or UTF-32) is considered useful."

We can probably guess that someone will make the case for strict round-tripping, even if UTF-8 is used when compressed.

To guarantee symmetric encoding/decoding while allowing processors leeway during compression likely means that we would have to add a property or attribute for "originalEncoding" with default UTF8 and optional enumerations UTF16, UTF32.

On the other hand we can play the same JSON game and simply remain silent about it...

====================================================================================================
B Schema for JSON

change
xmlns:j="http://www.w3.org/2015/EXI/json"<http://www.w3.org/2015/EXI/json>

to
xmlns:j="http://www.w3.org/2016/EXI/json-1-draft"<http://www.w3.org/2016/EXI/json-1-draft>

====================================================================================================
Section D. Examples.

Another simple example (or a longer example) that shows parent-child nesting of JSON objects down a level would be useful.

====================================================================================================
Choice of words:  I usually find that the word "very" is superfluous and adds very little value...  Suggest removing it, no other wording is affected.

====================================================================================================
Attached is schema-for-json.xsd documentation in .pdf form (generated by XML Spy and Word) to facilitate review.

Check question:  it appears that the scope of the uniqueness constraint is limited to the map element it is defined within.
http://www.w3.org/TR/xmlschema-0/#specifyingUniqueness

====================================================================================================

v/r Don

On 12/16/2015 8:25 AM, Peintner, Daniel (ext) wrote:

All,

based on the feedback so far I integrated the following updates to the EXI for JSON document [1].

* marked the exi:decimal datatype for the other element at risk
* created non-normative appendix section for "Design Decisions"

The document seems functionally complete and I would like to ask everyone for a final review and feedback. The plan foresees a first publication by the beginning of next year.

Thanks,

-- Daniel

[1] http://www.w3.org/XML/EXI/docs/json/exi-for-json.html


________________________________
Von: Efficient XML Interchange Working Group Issue Tracker [sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>]
Gesendet: Dienstag, 8. Dezember 2015 16:53
An: public-exi@w3.org<mailto:public-exi@w3.org>
Betreff: ACTION-733: Go over exi for json draft and ask the group for review in preparation for publication

ACTION-733: Go over exi for json draft and ask the group for review in preparation for publication

https://www.w3.org/2005/06/tracker/exi/actions/733


Assigned to: Daniel Peintner


all the best, Don




--

Stephen D. Williams sdw@lig.net<mailto:sdw@lig.net> stephendwilliams@gmail.com<mailto:stephendwilliams@gmail.com> LinkedIn: http://sdw.st/in


V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407

AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres


Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
Received on Friday, 15 January 2016 04:58:56 UTC