Re: [xml-dev] The perils of using the @ symbol in JSON key name ...mappi

This does not address the original question, but I wanted to note that JSON-LD[1], a W3C standard that is gaining traction as a serialization format for RDF linked data, employs the "@" symbol as a core feature of its syntax[2]. To the extent that we want to promote interoperability between the XML and RDF worlds (and are willing to concede the failure of RDF/XML), then I think methods for accommodating JSON in XML (as in Hans-Juergen's example) are an important recourse.

--Tim

[1] http://json-ld.org/
[2] http://www.w3.org/TR/json-ld/#h3_syntax-tokens-and-keywords

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

On Mon, Aug 17, 2015 at 12:31 PM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

I think it is important to be aware of the diversity of problems and constraints. As Ghislain said, performance may be so critical that working with JSON directly may be the best, perhaps even only option. Another good reason for treating JSON as JSON is given when using _javascript_, where JSON immediately translates into objects. But in many cases XPath, XQuery, XSLT and XSD offer such advantages that working with XML node trees is highly desirable.

Concerning the "cost" of transformation one should also remember the fact that the program works with an internal representation anyhow, not the document text. So one must take care not to confuse the mental transformation ("This is JSON, so to use it as XML I have to transform it, haven't I?") with any actual one - there is none, there is only a parsing of text into internal representation and a serialization of internal representation into text. So if the input is JSON text, treating it as XML only involves an *alternative* parsing and an *alternative* serialization, not any additional transformation.

Concerning XML representations of JSON, there are quite a few variants which do not put any constraints on the JSON instance and allow (together with a corresponding serialization function) loss-less roundtripping. In other words: the JSON work can be done by XQuery/XSLT operations.

A notable example is given by BaseX, an open source XQuery processor + XML database ( basex.org ). It offers an extension function json:parse which produces a highly useful XML representation, mapping JSON member names to XML element names by retaining valid name characters and transforming invalid ones to Unicode numbers preceded by an underscore (e.g. foo_0020bar for element name "foo bar"). A full example see below. So avoidance of "@" and other invalid name characters is not necessary, but it makes the resulting XML (and hence XPath expressions) nicer. So yes, if designing JSON formats, I would as a rule do like Roger suggests.

Kind regards,
Hans-Juergen

PS: Below an example showing how to get XML representations of arbitrary JSON, ready to be processed with XPath, XSLT, etc.

XQuery code:
   json:parse(unparsed-text($uri))

XML Result:

<json type="object">
<address type="object">
    <street>21 2nd Street</street>
    <city>New York</city>
    <code type="number">10021</code>
</address>
<phone type="array">
    <_ type="object">
      <type>home</type>
      <number>212 555-1234</number>
    </_>
    <_ type="object">
      <type>mobile</type>
      <number type="number">1327724623</number>
    </_>
</phone>
<nonXmlNames type="object">
    <_0040>elem name: @</_0040>
    <_0040foo>elem name: @foo</_0040foo>
    <_0031>elem name: 1</_0031>
    <foo_0023bar>elem name: foo#bar</foo_0023bar>
    <foo_0023_0021bar>elem name: foo#!bar</foo_0023_0021bar>
    <foo_0020bar>elem name: foo bar</foo_0020bar>
</nonXmlNames>
</json>

JSON input:
{
"address": {
    "street": "21 2nd Street",
    "city": "New York",
    "code": 10021
},
"phone": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "mobile",
      "number": 1327724623
    }
],
"nonXmlNames": {
     "@" : "elem name: @",
     "@foo" : "elem name: @foo",
     "1" : "elem name: 1",
     "foo#bar" : "elem name: foo#bar",
     "foo#!bar" : "elem name: foo#!bar",
     "foo bar" : "elem name: foo bar"
}
}

Ghislain Fourny <g@28.io> schrieb am 17:33 Montag, 17.August 2015:

Hi Roger,

I think it depends on the use case. If you have full control over the
JSON documents at hand, you may consider introducing restrictions such
as the example you mention, which allows you to have a mapping from
JSON strings to XML names and have a more compact mapping. If however
you have no control, engineering wisdom would probably encourage you
to pick a mapping that is capable of mapping the entire JSON language
to a reasonable extent (issues with special characters may still
arise), in order to avoid spending hours on manual fixes. I have John
Snelson's mapping in mind, which if my recollection is correct creates
XML such as

<pair name="@bar" type="string">...</pair>

instead, where this special character poses no issue.

Also, there are JSON technologies for schemas and queries out there
already, which you can easily find on a search engine. My
understanding is that the main issue is more about getting them
standardized across all industry players, and taking the time to make
sure that the obtained standards are well engineered -- like XML
technologies at W3C.

Converting JSON to XML has a price in terms of performance. I do not
wish to enter the simplicity debate between XML and JSON here, I think
it suffices to say that the conversion back and forth itself costs
something. If performance is really important, you may find it
desirable to work directly in the JSON world and stick to working on
the/a JSON data model in memory and on the storage layer.

Kind regards,
Ghislain

On Mon, Aug 17, 2015 at 4:18 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> In XML documents an element name cannot begin with the @ symbol; this is illegal:
>
> <@foo />
>
> Likewise an attribute name cannot begin with an @ symbol; this is illegal:
>
> <Document @id="..." />
>
> Schematron, XPath, and XQuery uses the @ symbol to denote "attribute"; for example:
>
> Book/@id
>
> JSON places no restrictions on the symbols used in JSON object keys; in particular, a key name may start with the @ symbol. For example, this is perfectly legal:
>
> {
> "@bar": "..."
> }
>
> At the present time in history XML has a much richer suite of tools than JSON. For example, there is nothing in the JSON tool suite that can match the ability of Schematron to declaratively express codependency rules; there is nothing in the JSON tool suite analogous to XSLT, XPath, or XQuery. So I would imagine that at least for the foreseeable future people will convert JSON to XML, Schematron, XSLT, XPath, and/or XQuery to leverage the rich XML tool suite.
>
> In light of this it seems reasonable to me that when designing JSON documents it would be well-advised to heed some of the XML naming requirements such as, "a name must not begin with an @ symbol".
>
> Question: would you please provide a concrete example to illustrate a problem with converting JSON to XML, Schematron, XSLT, XPath, and/or XQuery when the JSON contains key names that start with an @ symbol?
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php