[x3d-public] [x3dom-users] simple X3D -> JSON -> X3DOM, D3.js
Kristian Sons
kristian.sons at dfki.de
Sun Feb 22 05:55:34 PST 2015
Hi,
trying to structure the discussion a bit:
I guess the main question is if to a) start from XML encoding and use a
generic XML to JSON converter, or b) to start from the X3D data
structure and create something that reflects and fits well to the X3D
data structure.
If one uses a), one would have to pick one of the many existing (Don had
a nice overview in a previous mail).
If one designs something specific, there are a number of options:
O1: Encoding of containers fields
Background: X3D nodes may have multiple containers. In a format, one
needs the information to which container a child node belongs to.
_VRML encoding_: Container names are (explicit) in the format:
Appearance { material Material { diffuseColor 1 1 0} }
_X3D encoding_: Children specifiy the container using the containerField
attribute. The X3D XSD defines default container for each element, thus
it's not necessary to specify the containerField for most cases.
However, parsers need to know the XSD to exploit this information.
_Implementations_: Most implementations I have seen (or written myself)
use the type of child node to derive the right container. However, this
works only well because the X3D specification has only a few ambiguities
using this approach (e.g. MetadataSet has two fields of type
'X3DMetadataObject').
Options for JSON: Use explicit containers (resulting in something that
looks similar to VRML encoding), or an approach with an explicit
container field similar to XML encoding.
Pro VRML-like: JSON representation reflects X3D data structure, no magic
is happening, easy to parse into generic data structure without
additional knowledge (JSON.parse)
Pro XML-like: More concise, multi-container concept hidden (might be
easier for beginners)
O2: Encoding of primitive fields
Background: X3D has a collection of unstructured field types, e.g.
SFBool, MFBool, SFFloat, ..., JSON has basic JavaScript types: null,
boolean, number (double precision), string, object (associative array),
array
Options for JSON encoding: Map field types to best fitting JSON types or
decode every field as string
Pro best fitting: No additional parsing / knowledge required
Pro string: None I could imagine
O3: Encoding of special fields
Background: The JSON encoding will require some additional information
(e.g. 'containerField' for implicit containers, 'type' for explicit
containers). It might be useful to somehow mark those as special, e.g.
using a prefix (e.g. "_type", "@containerField", ...). Also, one could
think about encoding DEF/USE in a way it's supported by one of the many
JSON schema / JSON path implementations.
My personal favorits:
2) Specific JSON (no added value by generic conversion)
O1: Explicit containers (more consistent, no magic)
O2: Map fields to JSON types (no reason for strings)
O3: "_type"
Kristian
Am 21.02.2015 um 03:04 schrieb Michael Aratow:
> I think there is enough general interest and, as Don has surmised,
> communication mismatches, that a synchronous communication methodology
> (ie teleconference!!) be organized with the people who have provided
> such great comments and suggestions (eg John, Cecile, Don, Leonard,
> Johannes, Yvonne, Kristian and others).
>
>
> On 2/20/15 2:33 PM, Don Brutzman wrote:
>> As before, your insights are much appreciated. Thanks John.
>>
>> It is looking like there may be some terminology mismatches? That
>> might be an important cause of misunderstanding. Hoping to get clearer.
>>
>> When talking about "name" values, please clarify. Are your referring
>> to element and attribute names, or DEF/USE ID/IDREF names?
>>
>> In general, we have been trying to create a JSON representation for
>> X3D that is round-trippable with any other encoding.
>>
>> Not a goal is to create something incorrect or unusable. This isn't
>> a marketing activity. So no need for a BogusJSON or whatever, there
>> is simply no need for something broken.
>>
>> The X3dToJson.xslt is trying to take an XML-based .x3d scene and
>> produce a usable JSON representation. If information is lost, and
>> the result can't be written back out as the original scene, then an
>> encoding fails the round-trip test.
>>
>> Multiple approaches exist for converting XML to JSON. Some were
>> explored and compared on the earlier email threads. First one that
>> pops up on today's search is
>>
>> http://www.utilities-online.info/xmltojson/
>>
>> When given the HelloWorld.x3d scene, it replies with
>>
>> {
>> "X3D": {
>> "-profile": "Immersive",
>> "-version": "3.3",
>> "-xmlns:xsd": "http://www.w3.org/2001/XMLSchema-instance",
>> "-xsd:noNamespaceSchemaLocation": "
>> http://www.web3d.org/specifications/x3d-3.3.xsd ",
>> "head": {
>> "meta": [
>> {
>> "-name": "title",
>> "-content": "HelloWorld.x3d"
>> },
>> {
>> "-name": "description",
>> "-content": "Simple X3D scene example: Hello World!"
>> },
>> {
>> "-name": "created",
>> "-content": "30 October 2000"
>> },
>> {
>> "-name": "modified",
>> "-content": "23 November 2014"
>> },
>> {
>> "-name": "creator",
>> "-content": "Don Brutzman"
>> },
>> {
>> "-name": "Image",
>> "-content": "HelloWorld.tall.png"
>> },
>> {
>> "-name": "reference",
>> "-content": " http://en.wikipedia.org/wiki/Hello_world "
>> },
>> {
>> "-name": "reference",
>> "-content": "
>> en.wikipedia.org/wiki/Hello#\"Hello,_World\"_computer_program "
>> },
>> {
>> "-name": "reference",
>> "-content": "
>> http://en.wikibooks.org/w/index.php?title=Computer_Programming/Hello_world
>> "
>> },
>> {
>> "-name": "reference",
>> "-content": " http://www.HelloWorldExample.net "
>> },
>> {
>> "-name": "reference",
>> "-content": " http://www.web3D.org "
>> },
>> {
>> "-name": "reference",
>> "-content": "
>> http://www.web3d.org/realtime-3d/news/internationalization-x3d "
>> },
>> {
>> "-name": "reference",
>> "-content": "
>> http://www.web3d.org/x3d/content/examples/HelloWorld.x3d "
>> },
>> {
>> "-name": "reference",
>> "-content": "
>> http://X3dGraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes
>> "
>> },
>> {
>> "-name": "identifier",
>> "-content": "
>> http://X3dGraphics.com/examples/X3dForWebAuthors/Chapter01-TechnicalOverview/HelloWorld.x3d
>> "
>> },
>> {
>> "-name": "license",
>> "-content": "
>> http://www.web3d.org/x3d/content/examples/license.html "
>> },
>> {
>> "-name": "generator",
>> "-content": "X3D-Edit 3.3, https://savage.nps.edu/X3D-Edit"
>> },
>> {
>> "-name": "reference",
>> "-content": "HelloWorld.wrl"
>> },
>> {
>> "-name": "reference",
>> "-content": "HelloWorld.x3dv"
>> },
>> {
>> "-name": "reference",
>> "-content": "HelloWorld.x3db"
>> },
>> {
>> "-name": "reference",
>> "-content": "HelloWorld.xhtml"
>> },
>> {
>> "-name": "reference",
>> "-content": "HelloWorld.json"
>> }
>> ]
>> },
>> "Scene": {
>> "Group": {
>> "Viewpoint": {
>> "-DEF": "ViewUpClose",
>> "-centerOfRotation": "0 -1 0",
>> "-description": "Hello world!",
>> "-position": "0 -1 7"
>> },
>> "Transform": [
>> {
>> "-rotation": "0 1 0 3",
>> "Shape": {
>> "Appearance": {
>> "Material": {
>> "-DEF": "MaterialLightBlue",
>> "-diffuseColor": "0.1 0.5 1"
>> },
>> "ImageTexture": {
>> "-DEF": "ImageCloudlessEarth",
>> "-url": " \"earth-topo.png\" \"earth-topo.jpg\"
>> \"earth-topo-small.gif\"
>> \"http://www.web3d.org/x3d/content/examples/Basic/earth-topo.png\"
>> \"http://www.web3d.org/x3d/content/examples/Basic/earth-topo.jpg\"
>> \"http://www.web3d.org/x3d/content/examples/Basic/earth-topo-small.gif\"
>> "
>> }
>> }
>> }
>> },
>> {
>> "-translation": "0 -2 0",
>> "Shape": {
>> "Text": {
>> "-DEF": "TextMessage",
>> "-string": "\"Hello\" \"world!\"",
>> "FontStyle": { "-justify": "\"MIDDLE\" \"MIDDLE\"" }
>> },
>> "Appearance": {
>> "Material": { "-USE": "MaterialLightBlue" }
>> }
>> }
>> }
>> ]
>> }
>> }
>> }
>> }
>>
>> This varies from the current HelloWorld.json by including
>> X3D/head/meta* tags, using a different attribute prefix (- vice @),
>> and dropping comments and inclusion/exclusion of default attribute
>> values.
>> http://www.web3d.org/x3d/content/examples/HelloWorld.json
>>
>> So is the XML -> JSON conversion from
>> http://www.utilities-online.info/xmltojson producing illegal JSON too?
>>
>> Looking forward to continued scrutiny and improved understanding.
>>
>>
>> On 2/20/2015 11:15 AM, John Carlson wrote:
>>>
>>>>> On Feb 19, 2015 12:21 AM, "John Carlson" <yottzumm at gmail.com
>>>>> <mailto:yottzumm at gmail.com> <mailto:yottzumm at gmail.com
>>>>> <mailto:yottzumm at gmail.com>>> wrote:
>>>>>
>>>>> How does the X3D JSON encoding handle two Shapes or
>>>>> Transforms or Groups of the same type at the same depth in the
>>>>> tree with the same parent? Do you modify the tree structure
>>>>> significantly? I'm not that familiar with the schema. I just
>>>>> know you're going to have to do something else in JavaScript, even
>>>>> if your JSON parses and works. You can't use the JSON directly as
>>>>> Javascript. JSON != JavaScript. We desire a *JavaScript* and
>>>>> JSON encoding.
>>>>
>>>>
>>>> This is a crucial point and I'm really glad you are raising it.
>>>
>>> You're right it's a crucial point. It's so crucial I brought it up
>>> with Douglas Crockford. He said the standard did not need to be
>>> changed. What's important is how the standard is *used*. Say I'm in
>>> Java, and I'm reading in a A JSON object. What happens if I see a
>>> name in and object twice? What do I do? Do I instantly change my
>>> attribute to a list? How? Must I use a list for every single
>>> attribute because that's what is allowed by JSON? No, is the
>>> answer. JSON doesn't specify a set of name/list pairs, it specifies
>>> name/value pairs. JSON objects are meant to be associative arrays
>>> or struct or record as is mentioned in the standard. I asked
>>> Douglas to change the standard so names appeared only once in an
>>> object. He demurred. The thing is, it's the *use* that matters,
>>> and you're going to pull a lot of programmer's hair out and stick
>>> their fingers in electrical sockets if you continue to use names
>>> more than once in a JSON object. It violates the spirit of the
>>> standard if not the letter.
>>>
>>>> If we think about use cases for Javascript applications loading X3D
>>>> models, I think they are most interested in reusing geometry for
>>>> their own nefarious/magnificent purposes. Javascript programmers
>>>> are likely less interested in X3D event models, Scripts, protos and
>>>> whatnot. Library loaders might convert such things to match their
>>>> paradigm, or might also ignore non-geometry nodes completely.
>>>
>>> I guess what matters ultimately is that JSON parsers must reject
>>> names appearing in objects more that once. Also, please do not call
>>> your encoding JSON because it
>>> just *isn't*. If we must, programmers will move away from your JSON
>>> encoding, and use their own, as I have already done. All I'm
>>> actually doing is to asking you to make an X3D JSON standard which
>>> makes good sense, and if not, don't call it JSON. FJSON or Fake
>>> JSON might be more appropriate.
>>>>
>>>> Rephrase, Let JSON be JSON (a subset that is good for data objects)
>>>> and Javascript be Javascript (a full-blown programming language).
>>>>
>>>> Not trying to downplay or avoid anything, just looking at what the
>>>> most common uses of an X3D scene encoded as JSON might be.
>>>>
>>>> Such an idea actually brings us full circle to the design premise
>>>> of all the scene encodings (XML .x3d, Classic VRML .x3dv, binary
>>>> .x3db) which is to completely/compatibly represent an X3D scene,
>>>> period.
>>>>
>>>> If we achieve that with JSON, making common geometry constructs
>>>> easy for programmers to access, then great they will do so. If we
>>>> also try to tell them "For Advanced Graphics Using X3D JSON You
>>>> Must Program Your Javascript Application This Way" they will laugh.
>>>>
>>>> Viva la difference, programming styles and practices will always
>>>> vary and evolve. Whatever works.
>>>
>>> Yes, whatever works. Names or field slots appearing in an object
>>> more than once in a struct or record don't work in programmers'
>>> minds. You will force every value to be a list in their minds.
>>> Which may be what you intend. If so, then explicitly do that in
>>> your JSON output (my restructuring in my previous message). Don't
>>> force the programmer into cognitive overload. Please only have
>>> names appearing once in your objects, I beg you desperately, if you
>>> want your X3D JSON standard to be relevant. If not, then call it
>>> X3DON not *JS*ON
>>>
>>
>>
>> all the best, Don
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
_______________________________________________________________________________
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
_______________________________________________________________________________
More information about the x3d-public
mailing list