W3C home > Mailing lists > Public > public-xformsusers@w3.org > November 2015

JSON: another option for the format

From: Erik Bruchez <erik@bruchez.org>
Date: Fri, 20 Nov 2015 14:33:32 -0800
Message-ID: <CAAc0PEXwU7mXOZh1zUHZzfRHQs_8VrJ3Q0UMLeB57ohQ6p4rug@mail.gmail.com>
To: "public-xformsusers@w3.org" <public-xformsusers@w3.org>, Forms WG <public-forms@w3.org>
All,

The following JSON:

    {"g": [["a", "b", "c"], ["d", "e"]]}

currently translates to:

<json object="true">
    <g array="true">
        <_ name="" array="true" type="string">a</_>
        <_ name="" array="true" type="string">b</_>
        <_ name="" array="true" type="string">c</_>
    </g>
    <g array="true">
        <_ name="" array="true" type="string">d</_>
        <_ name="" array="true" type="string">e</_>
    </g>
</json>

If you were to use xf:repeat, xf:insert and xf:delete around this, you
would have to handle specifically the removal of the last element in
an array. For example:

    <_ name="" array="true" type="string">d</_>

becomes:

    <_ name="" array="true" />

instead of just deleting the last element.

If we switched to a scheme where arrays always have an enclosing
element, the mapping would be instead:

<json type="object">
    <g type="array">
        <_ type="array">
            <_ type="string">a</_>
            <_ type="string">b</_>
            <_ type="string">c</_>
        </_>
        <_ type="array">
            <_ type="string">d</_>
            <_ type="string">e</_>
        </_>
    </g>
</json>

There are some benefits to this:

- xf:repeat, xf:insert and xf:delete are much easier (see below)
- we don't need `array="true"`, but instead can use `type="array"`
- array elements are always anonymous (or their name can be ignored)
- the implementation of the conversion is a little simpler
- XPath expressions are more consistent

There are some drawbacks too:

- simple JSON cases without array nesting require slightly more complex XPath
- the XML is a little bigger due to the extra nesting

For example, say you want to reach the value "b". With the current scheme:

    g[1]/_[2]

or:

    g[1]/*[2]

With the proposed scheme:

    g/_[1]/_[2]

or:

    g/*[1]/*[2]

I think it's biggest appeal is the much easier xf:repeat, xf:insert
and xf:delete. To show this better, I created an XForms example
showing the two schemes here:

    https://gist.github.com/ebruchez/fd1c8d88f7966a9f0707

Handling xf:repeat, xf:insert and xf:delete is a puzzle with the older
scheme, but trivial with the proposed scheme. If have only shown Add
and Remove buttons for the inner repeat.

Feedback welcome,

-Erik
Received on Friday, 20 November 2015 22:34:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:45 UTC