[x3d-public] 4 things before pursuing further development
John Carlson
yottzumm at gmail.com
Thu Dec 30 05:22:45 PST 2021
*Bolded* is most important
Re: metadata containerField possible issues:
Here's the X3DUOM, bottom of *MetadataSet *ConcreteNode*,* AFAICT:
<containerField default="value" type="*containerFieldChoicesMetadata*"/>
Here's the SimpleType from above type:
<SimpleType name="*containerFieldChoicesMetadata*"
baseType="xs:NMTOKEN"
appinfo="containerFieldChoicesMetadata lists the
allowed containerField enumeration values for Metadata nodes:
"value" if providing information and parent node is MetadataSet
collection, otherwise default "metadata" if providing
information about parent node."
documentation="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField">
<enumeration value="*metadata*"
appinfo="this node provides metadata information
regarding its parent node."/>
<enumeration value="value"
appinfo="parent node is MetadataSet, this node is
providing information as part of a MetadataSet collection."/>
</SimpleType>
So this shows to me that /metadata/ can be a containerField for
MetadataSet. *I know why /metadata/ is not within MetadataSet.java
alternate containerFields. * I will have to go back in email to figure
out what data file I was using. In other words, I looked at X3DUOM and
it looked okay, so I looked at the stylesheet, it looked like it didn't
even used the above enumeration, just the default and some hard-coded
stuff (under development?). I understand the nature of taking time to
apply patches.
I understand that I am having troubles communicating. All I can do is
try again, or give up, or take better care of myself.
At this point, I would welcome working with x3d.py instead of X3DJSAIL
for HAnim. See below.
*$ python JinLOA4.py **
**x3d.py package loaded, have fun with X3D Graphics!**
**Python-to-XML well-formed XML document test of XML output successful**
**Python-to-XML X3D 4.0 schema validation test of XML output successful**
**Python-to-VRML export of VRML output successful (still testing)**
**Python-to-JSON export of JSON output successful (still testing)**
**python x3d.py load and self-test complete for JinLOA4.py*
Looking good. Not so good my python code, which is based on X3DJSAIL.
This has been discussed.
*Here are some file sizes from JinLOA4 examples in X3DJSONLD. Note that
your python file size is approaching the uncompressed XML size. Woohoo!
Congratulations!**
*
*-rw-rw-r-- 1 coderextreme coderextreme 783722 Dec 24 16:42
c/net/coderextreme/data/JinLOA4.c**
**-rw-rw-r-- 1 coderextreme coderextreme 817997 Dec 24 16:42
cplusplus/net/coderextreme/data/JinLOA4.cpp**
**-rw-rw-r-- 1 coderextreme coderextreme 2075748 Dec 24 16:42
dart/net/coderextreme/data/JinLOA4.dart**
**-rw-rw-r-- 1 coderextreme coderextreme 1891361 Dec 24 16:42
data/JinLOA4.json**
**-rw-rw-r-- 1 coderextreme coderextreme **684157**Dec 24 16:39
data/JinLOA4.x3d**
**-rw-rw-r-- 1 coderextreme coderextreme **595602**Dec 24 16:42
data/JinLOA4.x3d.new**
**-rw-rw-r-- 1 coderextreme coderextreme 813298 Dec 24 16:42
java/net/coderextreme/data/JinLOA4.java**
**-rw-rw-r-- 1 coderextreme coderextreme 808820 Dec 24 16:45
java/net/x3djsonld/data/JinLOA4.java**
**-rw-rw-r-- 1 coderextreme coderextreme 1240299 Dec 24 16:42
node/net/coderextreme/data/JinLOA4.js**
**-rw-rw-r-- 1 coderextreme coderextreme 1078827 Dec 24 16:42
node/net/ecma/data/JinLOA4.mjs**
**-rw-rw-r-- 1 coderextreme coderextreme 932175 Dec 24 16:20
node/net/x3djsonld/data/JinLOA4.js**
**-rw-rw-r-- 1 coderextreme coderextreme 700470 Dec 24 16:42
python/net/coderextreme/data/JinLOA4.py**
**-rw-rw-r-- 1 coderextreme coderextreme **685190**Dec 24 16:48
python/net/x3djsonld/data/JinLOA4.py**
**-rw-rw-r-- 1 coderextreme coderextreme 807415 Dec 24 16:42
vrml/net/coderextreme/data/JinLOA4.js*
*
*
*Also, unindented JSON approaches unindented XML *.x3d.new:*
*data$ cat JinLOA4.json |sed 's/^ *//' |wc**
** 11125 12961 **601583*
Here's the files I've restored to "golden" to sync up:
(venv) coderextreme at coderextreme-Kubuntu20:/c/x3d-code/www.web3d.org$
svn revert --depth=infinity .
Reverted 'x3d/stylesheets/X3dToNodeJS.xslt'
Reverted 'x3d/stylesheets/python/build.xml'
Reverted 'x3d/stylesheets/X3dToJson.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToVrml97.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToPython.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToJava.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToNodeJS.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToHtml.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dTidy.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToJson.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToX3dom.xslt'
Reverted 'x3d/stylesheets/java/lib/stylesheets/X3dToXhtml.xslt'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-3.0.xsd'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-3.1.xsd'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-4.0.xsd'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-3.2.xsd'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-3.3.xsd'
Reverted 'x3d/stylesheets/java/lib/specifications/x3d-schema-changelog.txt'
Reverted 'x3d/stylesheets/java/examples/build.xml'
Reverted
'x3d/stylesheets/java/src/org/web3d/x3d/util/x3duom/X3DUnifiedObjectModel40.java'
Reverted 'x3d/stylesheets/java/build.xml'
Reverted 'x3d/stylesheets/build.xml'
(venv) coderextreme at coderextreme-Kubuntu20:/c/x3d-code/www.web3d.org$
svn diff .
(venv) coderextreme at coderextreme-Kubuntu20:/c/x3d-code/www.web3d.org$
Thus all my ditzing with my local sourceforge mirror has been undone.
While I'm fixing it, you can finish your deployments.
**
John
On 12/28/21 18:00, Brutzman, Donald (Don) (CIV) wrote:
> Hi John, thanks for call today. Here is reply to your questions.
>
> 1. Version increment in X3DPSAIL’s setup.py
>
> The version number is incremented each time there is a new release. It is not modified otherwise.
>
> New releases are announced on the mailing list and are directly inspectable at pypi, the Python Packaging Index. PyPi currently reports last update as version 4.0.45 on 8 December 2021.
>
> *https://pypi.org/project/x3d
>
> Thus you can always know what the latest version number is.
>
> 2. Stiffness parameter type or conversion in x3d.py
>
> Already reported several times on mailing list, thanks to your original inquiry, there is a question whether they should be MFFloat or SFVec3f. I am awaiting time for a phone call with Dick Puk to confirm. Until then, the issue remains open.
>
> Currently everything deployed for X3D 4.0 for stiffness, ulimit, llimit is SFVec3f with default 0 0 0. After we discuss we will be able to update X3D4 Architecture CD1 draft and Mantis.
>
> All changes are checked in promptly. As usual you can check sourceforge for current settings, even when full deployment takes a day or two.
>
> All changes are applied to all ~4000 examples so we have a robust and extensive suite of unit tests.
>
> We have updated X3D Validator locally, also fixed log4j security vulnerability and some other small issues. You can always check the date at the bottom of that page to confirm when the latest update was.
>
> 3. Fix or remove alternate containerFields in X3DJSAIL. /metadata/ alternate in MetadataSet.java. Discussion of alternate containerField enumerations in X3DUOM.
>
> Also reported on mailing list last week. X3D3 and X3D4 containerField corrections relevant HAnimHumanoid/Metadata have been applied and deployed to the models in X3D Examples Humanoid Animation archives, with most subsequent changes now deployed.
>
> Authors modify the name of a containerField to correctly show the field relationship to the parent. You should never (i repeat Never Never Never) need to touch alternative containerField sources in underlying X3DJSAIL code.
>
> 4. llimit and ulimit default values fixed in X3DJSAIL.
>
> As X3DJSAIL date at bottom of home page indicates, that build has not been updated yet. I am applying the log4j security fix before updating that. Real Soon Now hopefully.
>
> Thanks for your reports. Once again, if you are building your own versions, you must use latest X3D DTD Schema and X3DUOM. All dates are inspectable. If we get those ground-truth versions fixed, all of the other changes are handled sooner or (sometimes) later.
>
> It's been a productive year. Have fun with X3D! 8)
>
> v/r Don
>
> ________________________________________
> From: x3d-public<x3d-public-bounces at web3d.org> on behalf of John Carlson<yottzumm at gmail.com>
> Sent: Sunday, December 26, 2021 20:07
> To: X3D Graphics public mailing list
> Subject: [x3d-public] 4 things before pursuing further development
>
> Summary of things to fix:
> 1. Version increment in X3DPSAIL’s setup.py
> 2. Stiffness parameter type or conversion in x3d.py
> 3. Fix or remove alternate containerFields in X3DJSAIL. /metadata/ alternate in MetadataSet.java. Discussion of alternate containerField enumerations in X3DUOM.
> 4. llimit and ulimit default values fixed in X3DJSAIL.
>
> Further development:
>
> TL;DR — Summary: HAnim Java and maybe Python needs work.
>
> In addition, I recommend running Java code generation and invocation for HAnim .x3d examples. I realize that my code is more robust during compilation, or at least it was. I have updated my HAnim examples. I need one meeting with Don and Joe to resolve issues beyond large code. Notification of further changes to HAnim examples welcome. Validators will be useful here. JSON output from Java not currently feasible because there are warnings, even beyond large code exceptions. We may also consider python HAnim, which run into the same problems as Java in my case. I have not tried HAnim with Don’s python generated code much.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211230/0cd69047/attachment-0001.html>
More information about the x3d-public
mailing list