#45 Please accept my changes to X3DJSAIL. I place my changes in the public domain.

[John W Carlson]

Here are changes that I've been maintaining in X3DJSAIL, allowed containerFields in X3DJSAIL, support for NavigationInfo.type in X3dToJson.xslt, and changes for X3dToNodeJS.xslt (for ES6 imports--untested). I do hope you accept the first two sets of changes. Thanks. I place any changes I make in the Public Domain.

[Don Brutzman]

For X3dToJson.xslt am seeing only one change

• < ! - - single string - - >
• not((local-name(..)='NavigationInfo') and ((local-name()='type') or (local-name()='transitionType'))) and (($attributeType = 'SFString') or

However, NavigationInfo fields type and transitionType are type MFString, not SFString.
* https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/navigation.html#NavigationInfo

Therefore, sorry but your change does not make sense. The parentheses in your version seem unbalanced (from a logic perspective) as well, when considered together with the other expressions in that test. Not accepted as is.

As usual, recommend a short precise issue report that provides an example of correct X3D producing incorrect JSON. This node is so common and simple that two single-line fragments will be sufficient. I am then able to handle any changes to the conversion stylesheet(s).

Once again I also request that only one issue be provided per ticket, so that multiple resolutions do not get intertwined and confused.

[John W Carlson]

The parentheses will match up when you put starting and closing parentheses
next to the open and close quotes, in other words, they match up, with
"and" in the middle. The intention is to NOT treat NavigationInfo.type as
an SFString, so that instead of matching the SFString test, it will skip
down to the MFString section. If a

Please see some JSON files with NavigationInfo.type and see that they are
being treated like MFStrings (JSON strings), not JSON array of strings.

See that this rendering is clearer:

                <xsl:when test="not((local-name(..)='NavigationInfo')

and ((local-name()='type') or (local-name()='transitionType'))) and
(($attributeType = 'SFString') or
not(local-name() ='url') and
not(ends-with(local-name(),'Url')) and
((local-name()='value') and

((contains(local-name(../..),'Proto') or
contains(local-name(../../..),'Proto')) and
((../@type='SFString') or
($fieldValueType='SFString'))) or
(local-name()='DEF') or
(local-name()='USE') or (local-name()='class') or
(local-name()='containerField') or
(local-name()='fromField') or
(local-name()='fromNode') or (local-name()='toField') or
(local-name()='toNode') or
(local-name()='name') or
(local-name()='description') or (local-name()='accessType') or
(local-name()='marking') or
(local-name()='description') or
(local-name()='nodeField') or
(local-name()='protoField') or
((local-name()='type') and
not(local-name(..)='NavigationInfo'))))
">

I don't see why your logic is better? I just know that when I look at the
JSON with your version, NavigationInfo.type is not a JSON array.

The first part means, if NavigationInfo and type (or transitionType) are
present, fail the SFString test, and drop down to MFString test (not
pictured).

I've tried your version many times, and there's no JSON array, so I
continually patch stuff. My logic keeps your logic, but fixes the case.
for NavigationInfo.type.

I don't know about transitionType, or why I added that.

So maybe we both need to investigate each other's logic some more. I did
some bad formatting, apologies.

John

[John W Carlson]

To tell you the truth, I got so confused with your SFString case, that I
just added a case for NavigationInfo.type/transitionType that would NOT
match any SFString.

We''ve already been through correct and incorrect cases.

Here's an incorrect case:
https://www.web3d.org/x3d/content/examples/Basic/ChemicalMarkupLanguage/Oxytocin.json

[image: image.png]

Here's a corrrect case:

https://raw.githubusercontent.com/coderextreme/X3DJSONLD/refs/heads/master/src/main/data/Oxytocin.json

[image: image.png]

I'm not saying my logic is the best, I'm just trying to make it so that
type and transitionType in NavigationInfo are treated the MFStrings, like
the url fields.

[Don Brutzman]

You have once again overloaded my buffer. I do not have time to investigate logic trails of long console logs, and frankly they seldom matter. Please stop.

Rephrasing prior request: please simply send
* valid 1-line .x3d NavigationInfo with type attribute
* failing 1-line .json NavigationInfo with type attribute
* goal 1-line .json NavigationInfo with type attribute

[John W Carlson]

valid 1-line .x3d: <navigationinfo type=""EXAMINE" "FLY" "ANY""></navigationinfo>
failing 1-line .json: { "NavigationInfo": {"@type":"\"EXAMINE\" \"FLY\" \"ANY\""}},
goal 1-line .json: { "NavigationInfo": {"@type":["EXAMINE","FLY","ANY"]}},

Maybe run a few test cases with viewing in X_ITE or X3DOM. I'm not sure how NavigationInfo.type actually works for those to browsers. Let's make sure we produce something that works in the browser. I am confident that X_ITE and Sunrize will work, but I don't exercise alternate NavigationInfo.types, ever. I have not stayed up to date with developments in X_ITE or X3DOM.

What I'm trying to do is match the spec, here (search for NavigationInfo):

https://www.web3d.org/x3d/stylesheets/X3dToJson.html

If you have something that says something else, in the working draft, that would work for me.

If we want to change the specification, that might be possible, but that would probably affect create3000 and probably X3DOM, unless they've adapted to X3dToJson.xslt as is already.

[Don Brutzman]

For CreateX3dSceneAccessInterfaceJava.xslt there is no explanation of what you are trying to do, nor a repeatable example.

Following close inspection, it looks like you think that Coordinate node can also be contained as a "controlPoint" field in a /NurbsPatchSurface parent/

The relevant specification paragraph is
* 27.4.6 NurbsPatchSurface
* https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/nurbs.html#NurbsPatchSurface

NurbsPatchSurface : X3DNurbsSurfaceGeometryNode {
SFNode [in,out] controlPoint NULL [X3DCoordinateNode]

So yes, that is an allowed containerField value for Coordinate node. The omission that you identified is something I can fix. Change accepted... more corresponding work follows.

I checked X3dUnifiedObjectModel-4.0.xml and it is OK, the definition for containerFieldChoicesX3DCoordinateNode includes controlPoint as an allowed field. So no further changes needed in X3D XML Schema and X3DUOM. That further means that X3DJSAIL and X3DPSAIL ought to allow construction of such a scene.

TODO: we need an .x3d test scene to check for proper conversion.

TODO: I also need to check X3D-Edit handling of containerField for Coordinate, CoordinateDouble, and GeoCoordinate nodes.

TODO: I also need to check other conversion stylesheets to see if similar problems appear elsewhere.

[John W Carlson]

Here's a good example .x3d test scene. We've seen it before, since you sent it to me today!

Use X3DJSAIL CommandLine -validate to see the fix! I realize that there may be a bug lurking in the Java scene, which probably neither of us can fix. For that reason, I will provide Java, which should technically produce output that is NOT viewable, but once you include the missing containerField="controlPoint" in the output .x3d, it is viewable! I will also attach the output with containerField="controlPoint" added to the NurbsPatchSurface Coordinates, called mobiusDon.new.java.x3d. Adding the cotainerField is the first step in getting the output viewable.

[John W Carlson]

Here's the Java:

[Don Brutzman]

Thanks for possible test model. I opted instead for a tried-and-true example, one of several in the X3D Basic Example Archives.
* X3D Example Archives: Basic, NURBS, Nurbs Patch Surface Example
Animated NURBS patch
* https://www.web3d.org/x3d/content/examples/basic/NURBS/NurbsPatchSurfaceExampleIndex.html

Results with updated X3DJSAIL:
C:\x3d-code\www.web3d.org\x3d\content\examples\Basic/NURBS//NurbsPatchSurfaceExample.x3d converted to NurbsPatchSurfaceExample.java
[meta] name='warning' content='missing default values for knot and weight array fields in NurbsPatchSurface (weight default: all 1 values) ; not required by X3D specification, but some browsers may fail without them.'
[meta] name='warning' content='under development, needs to be upgraded to final version of X3D NURBS nodes'
Compiling 1 source file to C:\x3d-code\www.web3d.org\x3d\content\examples\Basic\classes
now run the java model for self-validation:
java -classpath classes;lib/X3DJSAIL.4.0.full.jar Basic.NURBS.NurbsPatchSurfaceExample
Build this X3D model, showing validation diagnostics...
Basic.NURBS.NurbsPatchSurfaceExample self-validation test confirmation:
<meta content="missing default values for knot and weight array fields in NurbsPatchSurface (weight default: all 1 values) ; not required by X3D specification, but some browsers may fail without them." name="warning">
<meta content="under development, needs to be upgraded to final version of X3D NURBS nodes" name="warning">

---

Two files created using X3DJSAIL: NURBS//NurbsPatchSurfaceExample_JavaExport.x3d, .x3dv
Validate NURBS//NurbsPatchSurfaceExample_JavaExport.x3d using X3D XML DTD...
1 file(s) have been successfully validated.
Validate NURBS//NurbsPatchSurfaceExample_JavaExport.x3d using X3D XML schema...
Validate NURBS//NurbsPatchSurfaceExample_JavaExport.x3dv using castle-model-converter.exe...

Stylesheet change committed.
* allow containerField "controlPoint" /NurbsPatchSurface parent/
* https://sourceforge.net/p/x3d/code/37352/ (however code too large to see diff online)

X3DJSAIL update released, also including recent stylesheet corrections for NavigationInfo.type conversion into JSON.

Remaining TODO: I also need to check X3D-Edit handling of allowed containerField for Coordinate and CoordinateDouble nodes. GeoCoordinate is irrelevant for NurbsPatchSurface.

[John W Carlson]

X3dToJson.xslt looks good, proceeding with X3DJSAIL distribution copy

[Don Brutzman]

This was also documented in several locations
* X3D Scene Authoring Hints: containerField Variations for comprehensive list
* X3D Tooltips: Coordinate.containerField
* X3D Tooltips: CoordinateDouble.containerField
* X3DJSAIL Coordinate setContainerField() (now that it is added to X3D XML Schema, X3DUOM

X3D-Edit was missing these choices for Coordinate/CoordinateDouble, some others were missing too. Now corrected.

Looks like this issue can be closed.

[John W Carlson]

okay. I will try to double check whether the controlPoint containerField is output from X3DJSAIL or not this evening, and open up another ticket if not. Actually two tickets, one for Normal nodes under HAnimHumanoid ("skinNormal" containerField). I will generate Java from mobiusDon.x3d and another model created by Aaron, using X3dToJava.xslt, confirm that set/addSkinNormal() and set/addControlPount() are in the Java source, then check the XML output from the Java.