[x3d-public] How should CAD -shape containerField be expressed in X3DJSAIL (Problem with Object Model, Schema)

yottzumm at gmail.com yottzumm at gmail.com
Wed Feb 22 13:25:05 PST 2017


I finally tracked this down:

I also question the Object Model, where under:
<ConcreteNode name="CADFace">

It lists:

<containerField name="children"/>

children should be shape?  Or is the JSON/stylesheet wrong?

I will check the xml schema next.  It also has children as the container Field.

Something here needs to be resolved.   This could be quite a big thing with validating various XML files, since the schema could be wrong.

If the Object Model and Schema are correct, could you please fix the X3D resources JSON and X3D examples?  The X3D example says it’s supposed to validate and work, so…   Changing to shape may be more restrictive, yet check for validation better.

At a minimum, the Java Code, Object Model and Schema should list an alternate containerField, I think, if the JSON and XML are passing validation.  Probably the containerField isn’t being validated?

Thanks,

John
Sent from Mail for Windows 10

From: yottzumm at gmail.com
Sent: Wednesday, February 22, 2017 3:43 PM
To: Roy Walmsley
Cc: 'Don Brutzman'; 'X3D Graphics public mailing list'
Subject: RE: How should CAD -shape containerField be expressed in X3DJSAIL

Sadly, I do not have the JSON available which does not have the -shape field which was produced from X3DJSAIL.  You will probably have to run the code to see it.  I will work on getting this code compiling again, with the new serializer.

However, I believe the JSON generated is something like this:

{ "CADFace":
  {
    "@name":"outerSurface",
    “-children”: [
       "Shape": {...}
    ]
  }
}

You’ll have to run the code I provided to be sure.  I may get back to this as some point, since I don’t think it’s fixed, but I don’t think you can just brush this off.  Don?

Specifically, I am looking for Java code which will produce -shape from toFileJSON() with X3DJSAIL.  The X3dToJSON.xslt should have full access to the X3DSchema and should be able to produce a -shape field, but I think that X3DJSAIL should do it.  I will investigate further.

Specifically, I question the code in CADFaceObject.java:

        /** containerField describes typical field relationship of a node to its parent.
         * Usage is not ordinarily needed when using this API, default value is provided for informational purposes. */
        String containerField_DEFAULT_VALUE = "children";

        /** containerField describes typical field relationship of a node to its parent.
         * Usage is not ordinarily needed when using this API, alternative values are provided for informational purposes. */
        String[] containerField_ALTERNATE_VALUES = { "children" };

When after the imports, it says:

* <i>X3D node tooltip</i>:  (X3D version 3.1 or later) CADFace holds geometry representing one face in a Computer-Aided Design (CAD) CADPart. CADFace can only contain a single Shape or LOD node (with containerField='shape').

John

Sent from Mail for Windows 10

From: Roy Walmsley
Sent: Wednesday, February 22, 2017 6:36 AM
To: yottzumm at gmail.com
Cc: 'Don Brutzman'; 'X3D Graphics public mailing list'
Subject: RE: How should CAD -shape containerField be expressed in X3DJSAIL

John,

When going from JSON to XML you have all the information to generate a “containerField” attribute for the XML encoding. No magical figuring out is required.

When you parse a node in a JSON encoded file you will see that a node, e.g. “CADFace” as per the example we detailed earlier, lists the “-shape” field, with the “Shape” node being a child object of that field. So, when you convert to the XML encoding, you translate the “CADFace” node. Then, noting that the “Shape” node is contained in a “shape” field, as you translate the “Shape” node you add an attribute “containerField=’shape’” to the “Shape” element in the XML, with the “Shape” element being a child of the “CADFace” element. 

So, in summary, the “containerField” attribute tells a node which field of its parent node it is to be assigned to. Here is a shortened summary. First the JSON encoding:

{ "CADFace":
  {
    "@name":"outerSurface",
    "-shape":
      { "Shape": {...}
      }
  }
}

When converted to XML it becomes:

<CADFace name="outerSurface">
  <Shape containerField="shape">
    ...
  </Shape>
</CADFace> 

Expressing this another way – I have a C++ application that can read both JSON and XML encoded files.

When it reads the JSON file it starts to read the “CADFace” object, so creates an instance of “CADFace”. It reads the “@name” property, and so sets the “name” field in the instance to “outerSurface”. It then reads the “-shape” property, and, remembering that this is the “shape” field, reads the “Shape” object, creating an instance of “Shape”. It then sets a reference to that “Shape” instance as the value of the “shape” field in the “CADFace” instance. Then it would go on to read the rest of the “CADFace” object, if there was more, before setting the reference to the instance of “CADFace” to the value of the appropriate field in the appropriate parent instance.

When reading the XML encoded file my application reads the “CADFace” element, and creates an instance of “CADFace”. It then goes on to read any children of “CADFace”, and finds the “Shape” element. It reads and creates an instance of “Shape”. It then needs to know which field of the “CADFace” instance to set the reference to the “Shape” instance. So, it checks the “containerField” attribute for the “Shape” element. Finding this to be “shape” it sets the value of the “shape” field in the “CADFace” instance to the reference to the “Shape” instance.

Now, what would have happened if the “Shape” element did not have the “containerField” attribute specified in the XML encoding. My application could have two fall backs. The first is the DTD and/or the XML schema. My application can read either of these, and hence find the default value of “containerField”. In the case of “Shape”, that is “children”. The second is to hard wire the default into the code, something I have not yet done. Since “CADFace” does not have a “children” field, the read would fail.

All the best,

Roy

From: yottzumm at gmail.com [mailto:yottzumm at gmail.com] 
Sent: 21 February 2017 23:00
To: Roy Walmsley <roy.walmsley at ntlworld.com>
Cc: 'Don Brutzman' <brutzman at nps.edu>; 'X3D Graphics public mailing list' <x3d-public at web3d.org>
Subject: RE: How should CAD -shape containerField be expressed in X3DJSAIL

I would just like to see some consistency between output from the X3dToJson.xslt and X3DJSAIL.  If this means modifying my Java code, tell me how to do it.  I think the XML generated by X3DJSAIL is WRONG!  It’s kind of hard to capture because it’s an intermediate file.  Perhaps someone could generate XML from X3DJSAIL and compare it to the original.  It takes all my spare time to do the JSON.  That is, change toFileJSON to some XML generating method in the Java and run it.

Since I am producing XML from JSON, I may actually need the containerField in the JSON (unless I can magically figure it out).  Consider this for the V4.0 standard.  Otherwise, I may not be able to produce proper XML.

Thanks,

John

Sent from Mail for Windows 10

From: Roy Walmsley
Sent: Tuesday, February 21, 2017 8:22 AM
To: yottzumm at gmail.com
Cc: 'Don Brutzman'; 'X3D Graphics public mailing list'
Subject: RE: How should CAD -shape containerField be expressed in X3DJSAIL

John,

JSON, just like the VRML encoding, does not need containerField. This is because the child content is listed below the specific field that contains it. So, for example, consider a CADFace listing from the JSON file you attached:

{ "CADFace":
  {
    "@name":"outerSurface",
    "-shape":
      { "Shape":
        {
          "-children":[
            { "#comment":"note solid='true' and so one-sided external rendering only"
            }
          ],
          "-geometry":
            { "Cylinder":
              {
                "@bottom":false,
                "@height":3,
                "@radius":2,
                "@top":false
              }
            },
          "-appearance":
            { "Appearance":
              {
                "@DEF":"AppearanceGrey",
                "-material":
                  { "Material":
                    {
                    }
                  }
              }
            }
        }
      }
  }
}

The CADFace node has the value of two fields specified. The first is the “name” field, with the value “outerSurface”. The second is the “shape” field, with the value being the “Shape” node.

How does this appear in the XML encoding? It is :

<CADFace name="outerSurface">
  <Shape containerField="shape"><!--note solid='true' and so one-sided external rendering only-->
    <Cylinder containerField="geometry" bottom="false" height="3" radius="2" top="false"></Cylinder>
    <Appearance containerField="appearance" DEF="AppearanceGrey">
      <Material containerField="material"></Material>
    </Appearance>
  </Shape>
</CADFace> 

So could have been written as follows:

<CADFace name="outerSurface">
  <Shape><!--note solid='true' and so one-sided external rendering only-->
    <Cylinder bottom="false" height="3" radius="2" top="false"></Cylinder>
    <Appearance DEF="AppearanceGrey">
      <Material></Material>
    </Appearance>
  </Shape>
</CADFace> 

Notice that the “containerField” attributes have all been deleted. This might well fail to load. Why? Because, reference to the XML schema shows that the default value of “containerField” for the “Shape” node is “children”. However, CADFace does not have a “children” field. So, it is necessary to specify somehow which field the “Shape” node should be assigned to. Hence the “containerField” attribute.

In summary, in the X3D standard 19775-1 there is no “containerField”. In the ClassicVRML encoding 19776-2 there is no “containerField”. In the JSON encoding 19776-5 there is no “containerField”. It is, however, in the XML encoding 19776-1. This is the only text encoding that it appears in. Note that it would not be expected to be included in an implementation.  That is because, on loading into memory, and having created an instance of the “CADFace” node, the reading of the “Shape” node would create that instance, and then store the reference to it in the “shape” field of the “CADFace” node. So it is only required by the XML loader to determine which node field to add the child node reference to.

All the best,

Roy


From: yottzumm at gmail.com [mailto:yottzumm at gmail.com] 
Sent: 21 February 2017 06:38
To: Don Brutzman <brutzman at nps.edu>; Roy Walmsley <roy.walmsley at ntlworld.com>; X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: How should CAD -shape containerField be expressed in X3DJSAIL

Attached input JSON and converted Java.  The Java does not produce -shape in the output JSON.json file [ not provided—compile and run the Java ].  Is this OK?  I am currently using setShape in the Java.  Why doesn’t the JSON.json have the containerField?  Thanks!

John




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170222/a9580e34/attachment-0001.html>


More information about the x3d-public mailing list