[X3D-Public] x3d to json experiments & links of interest

Tue Jul 8 01:06:42 PDT 2014

Hi,

> Hi Don,
> 
> just a few comments from my side (and my experience having written some X3D parsers / toolkits):
> 
> JSON is actually kind of similar to the VRML syntax, with some advantages (it needs less context to parse). The common feature of JSON and VRML -- despite the optical similarities -- is to define multiple named array entries that can in turn contain structured content (often called "containers"). XML encoding has only _one_ container for child elements (called "children" in the API). That is what X3D in XML always suffered from: X3D requires an additional attribute to specify the container. This concept is well hidden using default values, but requires the XSD (i.e. context). And it suddenly pops up, once a user is dealing with the most underestimated concept of X3D: Prototypes. 
> 
> So I wonder why to (re-)import this flaw to JSON? Why not something like:
> 
> {
>    "type":"Group",
>    "children":[
>       {
>          "type":"Shape",
>          "appearance":{
>             "type":"Material",
>             "diffuseColor":[0.1,0.5,1]
>          },
>          "geometry":{
>             "type":"Box"
>          }
>       }
>    ]
> }

The typesystem allows to select the correct target fields for generic addChild() operations (e.g. performed by the XML-parser)
This is well defined and could be utilised in the json version again.

{ 
	"type":"shape",
	"children": [
	{
		"type":"shape",
		children: [
			{ 
				"type":"Material"
				"diffuseColor":[...]
			},
			{
				"type":"Box"
			}
		]
	}
}

Both versions have advantage and disadvantage which should be considered.

For me the big question is the field data encoding. 

- Is it always Strings (as in XML) or to we use the JSON types?
- Should we allow links to binary value container (similar to gltf?)
- Are MF-Fields always Arrays?

Best regards
Johannes

> 
> This style would clearly expose the container names and thus also help users who want to use the API.
> 
> Apart from the encoding, I wonder how useful a JSON representation is. From our experience, the advantages in terms of size is negligible compared to XML because the numbers make the main workload. To transfer heavy geometry and texture data, there are many other, more compelling alternatives (see papers from last and next Web3D :). 
> 
> Just my two cents :)
> 
>   Kristian
> 
> 
>> Still hoping to hear from x3dom developers on their use of JSON and relevant use cases of X3D in JSON form. 
>> 
>>> 6.  Suggested discussion points for the X3D teleconference and future followups. 
>>> 
>>> a.  What are the use cases for having X3D JSON available in JavaScript?  It would be good to spell them out and understand them well. 
>>> b.  Is there a good/consistent way for X3DOM to utilize such capabilities? 
>>> c.  Is there a way for Three.js or other javascript libraries to utilize such capabilities? 
>>> d.  Is there a single authoritative reference for JSON itself? and for JSON-XML conversions? 
>>> e.  Compare compression of a TestMesh.x3d.json.gz to TestMesh.x3db and TestMesh.x3d.exi 
>>>      (EXI will likely win because it includes data typing) 
>>> f.  Once a canonical form for X3D as JSON is established, add conversion capabilities to X3D-Edit and also autoconvert, test and publish JSON for all of the3800+ X3D Examples Archive scenes 
>>> g.  Decide if this capability needs to be defined in one of the X3D standards, or perhaps as an X3D best practice. 
>>> h.  Probably lots more... What else? 
>> 
>> More information on JSON <==> XML follows. 
>> 
>> ===================================================================== 
>> 
>> Don McGregor (who has translated the DIS protocol to JSON) reports the following ECMA standard for JSON. 
>> 
>> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf  (14 pages) 
>> 
>> It does not mention XML, and therefore does not address the potential use of - or @ (or whatever) characters to distinguish child JSON fields as elements or attributes. Absent any other specifications, this would seem to provide rationale for our defining an official JSON encoding for X3D. 
>> 
>> The following commercial posting discusses this issue a little: 
>>     XSLT and XPath for JSON 
>>     By Mark Joseph - May 6, 2008 
>>     https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-json 
>> 
>> ===================================================================== 
>> 
>> The following reference from json.org is also interesting: 
>> 
>>     JsonML.org 
>>     JSON Markup Language (JsonML) 
>> 
>>> JsonML (JSON Markup Language) is an application of the JSON (JavaScript Object Notation) format. The purpose of JsonML is to provide a compact format for transporting XML-based markup as JSON which allows it to be losslessly converted back to its original form. 
>>> 
>>> Native XML/XHTML doesn't sit well embedded in JavaScript. When XHTML is stored in script it must be properly encoded as an opaque string. JsonML allows easy manipulation of the markup in script before completely rehydrating back to the original form. 
>> 
>> This site also includes the following syntax definition for lossless round-trip conversion: 
>> 
>>     http://www.jsonml.org/syntax 
>> 
>>> Syntax Reasoning 
>>> 
>>> JsonML was designed for lossless roundtrip conversion between XML and JSON and to handle "mixed-mode content" (i.e., textual data outside of or next to elements). Key considerations were lossless two-way conversion and compactness of form. JsonML handles namespaces in the same way that XML 1.0 does: attributes for xmlns and tag names with colons. 
>>> 
>>> JsonML was never intended to be the way that everything that could be expressed in XML should be expressed in JSON. JsonML is the only transformation which can safely encode "mixed-mode" content in XML, which is a key characteristic in a markup language such as XHTML. Many other transformations exist for representing XML in a JSON format. 
>>> 
>>> Grammar (BNF) 
>>> 
>>> The following grammar represents how XML-based markup (e.g. XHTML) is encoded into JsonML. As per JSON, whitespace is permitted between tokens. 
>>> [...] 
>> 
>> ===================================================================== 
>> 
>> all the best, Don 
> 
> 
> -- 
> _______________________________________________________________________________
> 
> Kristian Sons
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
> Agenten und Simulierte Realität
> Campus, Geb. D 3 2, Raum 0.77
> 66123 Saarbrücken, Germany
> 
> Phone: +49 681 85775-3833
> Phone: +49 681 302-3833
> Fax:   +49 681 85775–2235
> 
> kristian.sons at dfki.de
> http://www.xml3d.org
> 
> 
> Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
> Dr. Walter Olthoff
> 
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> _______________________________________________________________________________
> 
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

---
Dr. Johannes Behr
Head of Department: Visual Computing System Technologies
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-510  |  Fax +49 6151 155-196
johannes.behr at igd.fraunhofer.de  |  www.igd.fraunhofer.de