Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The perils of using the @ symbol in JSON key name ...mappi
 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. 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@m...> 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@l... > subscribe: xml-dev-subscribe@l... > 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@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
