[x3d-public] ... need x3d.py python support for Script CDATA; name sourceCode vice sourceText for clarity
John Carlson
yottzumm at gmail.com
Sat Jan 15 17:25:42 PST 2022
Ultimately, we may want to put @sourceCode in all versions of the schema.
Let me know if you want to change @sourceCode to #sourceCode as well.
Right now, #sourceText is still present in the schema, as there are other
areas which need attention in the X3DUOM. Currently, there is only
sourceCode for Script. The Shaders need attention too. ShaderPart,
ShaderProgram, ??? Please update X3DUOM with due speed.
The schemas should be compatible with either #sourceText or @sourceCode. I
will begin testing JSON files with an updated version of X3dToJson.xslt (my
version).
SVN status:
At revision: 32828
On Sat, Jan 15, 2022 at 6:49 PM John Carlson <yottzumm at gmail.com> wrote:
> Updated schema with @sourceCode is here: X3DJSONLD/src/main/schema at
> master · coderextreme/X3DJSONLD (github.com)
> <https://github.com/coderextreme/X3DJSONLD/tree/master/src/main/schema>
> (I'm not sure of this link, pasted into GMail app, I actually meant
> https://github.com/coderextreme/X3DJSONLD/tree/master/src/main/schema
> Thanks!
>
> On Sat, Jan 15, 2022 at 5:16 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> I am currently having difficulty installing the node-java package. I
>> suggested taking the "java" entry out of package.json in X3DJSON in the
>> short term. I am rebuilding my system (have to reinstall maven, etc).
>> Once I get a partially working build, I will start working on a JSON schema
>> using current X3DUOM (I have to get that too).
>>
>> John
>>
>> On Sat, Jan 15, 2022 at 4:15 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> I am aware of setSourceCode in the Java binding and related FFIs and
>>> conversions to support x3d.py are in the works for x3djsonld.py. I’m
>>> pretty sure I look for a CDATASection (DOM converted from #sourceText)
>>> mostly in my serializers.
>>>
>>> It really is a “simple” change to replace #sourceText with sourceCode.
>>> What I am concerned about is the many JSON files which currently show
>>> schema problems and will cause alerts when testing.
>>>
>>> I agree that we should do one round of testing instead of two. We
>>> should make the change for sourceCode an NavigationInfo.type at the same
>>> time.
>>>
>>> The first 2 steps are to change JSON Schema and X3dToJson.xslt for both
>>> issues we are currently discussing.
>>>
>>> Thanks!
>>>
>>> John
>>>
>>> On Sat, Jan 15, 2022 at 3:45 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>>> Thanks for all feedback, Holger and John.
>>>>
>>>>
>>>>
>>>> Simple proposal for the moment: am working to demonstrate consistently
>>>> unescaped script code within Script node. We achieved that capability with
>>>> X3D JSON draft encoding, but didn’t use it anywhere else.
>>>>
>>>>
>>>>
>>>> While adding the capability to X3DUOM and Java (so far), it became
>>>> obvious that the term “sourceText” is ambiguous since typically the entire
>>>> model consists of source text (for XML, ClassicVRML, source code, etc.)
>>>>
>>>>
>>>>
>>>> This name is not yet in any of our X3D specifications so we are free to
>>>> change it… am suggesting “sourceCode” as a less ambiguous name, for
>>>> containing unescaped source code within Script, ShaderProgram or ShaderPart
>>>> node.
>>>>
>>>>
>>>>
>>>> No further improvements to “sourceCode” yet heard – if that name is OK,
>>>> then great. It seems clear when used in a sentence.
>>>>
>>>>
>>>>
>>>> We can certainly carry forward code support for the original
>>>> “sourceText” for a while, not trying to break experimental code/model
>>>> implementation and evaluation, but am thinking that we don’t want to
>>>> perpetuate two names forever, since that just leads to confusion and
>>>> inconsistency in years to come.
>>>>
>>>>
>>>>
>>>> - Wikipedia: Don't repeat yourself (DRY principle)
>>>> - https://en.wikipedia.org/wiki/Don't_repeat_yourself
>>>>
>>>>
>>>>
>>>> Hope this sounds sensible... thanks for continuing consideration.
>>>>
>>>>
>>>>
>>>> I’ll work on adding “sourceCode” capabilities to X3DPSAIL Python and
>>>> X3D Ontology Turtle next, continuing with regression testing.
>>>>
>>>>
>>>>
>>>> all the best, Don
>>>>
>>>> --
>>>>
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>>
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>>
>>>> X3D graphics, virtual worlds, Navy robotics https://
>>>> faculty.nps.edu/brutzman
>>>>
>>>>
>>>>
>>>> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *Holger
>>>> Seelig
>>>> *Sent:* Saturday, January 15, 2022 1:28 PM
>>>> *To:* X3D <x3d-public at web3d.org>
>>>> *Subject:* Re: [x3d-public] Possible issue with X3dToPython.xslt,
>>>> newly tested file from X3D4WA: need x3d.py python support for Script CDATA
>>>>
>>>>
>>>>
>>>> A good way to implement changes in parser/generator is to output new
>>>> style code, and parse new and old style code, ie. be backwardly compatible.
>>>> It depends on how much changes in X3D JSON encoding. If it is only the
>>>> change of #sourceText to #sourceCode then it is very easy to provide both
>>>> variations. If it is more than this, a detailed list of changes would be
>>>> very useful.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Holger
>>>>
>>>>
>>>>
>>>> Am 15.01.2022 um 22:12 schrieb John Carlson <yottzumm at gmail.com>:
>>>>
>>>>
>>>>
>>>> In other words, let’s fix known problems before creating new ones.
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On Sat, Jan 15, 2022 at 3:06 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>>
>>>> It’s higher priority for me to fix the X3dToJson.xslt so that
>>>> Navigation.type produces a consistent type of data. At this time, I don’t
>>>> know if it produces a JSON string or a JSON array. I believe the JSON
>>>> Schema says array. If we want it to be a string, okay, but can we change
>>>> all other MFStrings to output JSON strings in X3dToJson.xslt?
>>>>
>>>>
>>>>
>>>> Maybe I missed an email on this?
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On Sat, Jan 15, 2022 at 2:52 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>>
>>>> It’s just that people may already have JSON files working with X_ITE.
>>>> We will have to go through regression testing etc. We don’t have
>>>> scripting with X3DOM working yet except on some of my published work. And
>>>> even some of that is not working. AFAIK, all my scripts work ok in X_ITE.
>>>> So I would encourage us to tread carefully when modifying JSONParser.js
>>>> in X_ITE, and provide for a deprecation period.
>>>>
>>>>
>>>>
>>>> I don’t have to retest my shaders—they are in external files.
>>>>
>>>>
>>>>
>>>> If we decide to force a change to X3D JSON Schema, I will probably
>>>> slowly deprecate #sourceText in favor of sourceCode, but I doubt if all
>>>> this will happen overnight. My surgery was postponed and I want to
>>>> minimize impact on my wrists right now. That is, I will support
>>>> sourceCode and sourceText in parallel. I will have to figure out how the
>>>> new X3DUOM impacts all my python generators as well.
>>>>
>>>>
>>>>
>>>> I’m guessing you don’t actually have any Scripting working on those
>>>> older products you mention, so it didn’t really impact you until you wanted
>>>> to do python+scripting in Jupyter.
>>>>
>>>>
>>>>
>>>> I will look a bit into X3DUOM changes to see how much my other code is
>>>> impacted, or can be enhanced.
>>>>
>>>>
>>>>
>>>> There’s also probably X3DJSONLD.java and X3DJSONLD.cpp that need to be
>>>> changed.
>>>>
>>>>
>>>>
>>>> I would encourage maintaining at least a synonym “#sourceText” for
>>>> sourceCode.
>>>>
>>>>
>>>>
>>>> We should probably create a plan for updating JSONParser.js in X_ITE.
>>>>
>>>>
>>>>
>>>> I’m not really sure there will ever be a JSON encoding for X3D, but I’m
>>>> glad X3dToJson.xslt is being maintained as I don’t have a good replacement
>>>> yet.
>>>>
>>>>
>>>>
>>>> “someday” is today for me. What will it take to make X3D JSON a
>>>> standard? We already have two working implementations, AFAIK.
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On Sat, Jan 15, 2022 at 1:12 PM Brutzman, Donald (Don) (CIV) <
>>>> brutzman at nps.edu> wrote:
>>>>
>>>> I’ve got X3DUOM and Java working on my machine. Python, X3D Ontology
>>>> and Tooltips next.
>>>>
>>>>
>>>>
>>>> John, can we please change the JSON encoding to use “sourceCode”
>>>> instead of sourceText for consistency? I don’t think there is any
>>>> need for synonyms or backwards compatibility, the encoding hasn’t been
>>>> formalized yet and (someday) JSON Schema will help people confirm
>>>> correctness.
>>>>
>>>>
>>>>
>>>> - X3D to JSON Stylesheet Converter: Data Types
>>>> - https://www.web3d.org/x3d/stylesheets/X3dToJson.html#DataTypes
>>>>
>>>>
>>>>
>>>> Embedded source code for
>>>> Script <https://www.web3d.org/x3d/content/X3dTooltips.html#Script>,
>>>> ShaderPart
>>>> <https://www.web3d.org/x3d/content/X3dTooltips.html#ShaderPart> and
>>>> ShaderProgram
>>>> <https://www.web3d.org/x3d/content/X3dTooltips.html#ShaderProgram>
>>>> nodes
>>>>
>>>> CDATA (Character DATA) section
>>>> <[CDATA[ "world wild Web!" ]]>
>>>>
>>>> "#sourceText" string array containing original code, possibly escaped
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> all the best, Don
>>>>
>>>> --
>>>>
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>>
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>>
>>>> X3D graphics, virtual worlds, Navy robotics https://
>>>> faculty.nps.edu/brutzman
>>>>
>>>>
>>>>
>>>> *From:* John Carlson <yottzumm at gmail.com>
>>>> *Sent:* Friday, January 14, 2022 5:25 AM
>>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>
>>>> *Subject:* Re: Possible issue with X3dToPython.xslt, newly tested file
>>>> from X3D4WA: need x3d.py python support for Script CDATA
>>>>
>>>>
>>>>
>>>> I finally got a chance to think about this, and I think it will be good
>>>> to support legacy files by providing a synonym for
>>>> “#sourceText”—“sourceCode” as you say. If a particular binding can’t
>>>> provide for #sourceText, then sourceCode can be used as a fallback.
>>>>
>>>>
>>>>
>>>> We can discuss changes to the JSON WD Draft at some point.
>>>>
>>>>
>>>>
>>>> We will have to update X3D JSON schema as previously discussed
>>>> implicitly.
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On Tue, Jan 11, 2022 at 1:03 AM Brutzman, Donald (Don) (CIV) <
>>>> brutzman at nps.edu> wrote:
>>>>
>>>> 1. Following some initial testing, am happy to report that this
>>>> approach to embed source code in Script nodes seems consistently feasible
>>>> for X3DUOM, Python, Java and X3D Ontology all at once.
>>>>
>>>> It will take a little work to fully implement, but it should improve
>>>> the expressive power (meaning "fix a hole") in each of our
>>>> programming-language bindings.
>>>>
>>>> ------
>>>>
>>>> 2. In some sense embedding script code is already possible - you can
>>>> put such a program in first string contained in a Script url list - but in
>>>> practice that tends to be quite difficult because then all sorts of
>>>> obfuscating escaping of special characters has to take place.
>>>>
>>>> So having a separate place for source-code blocks is very helpful. The
>>>> X3D Architecture recognizes this possibility and defines corresponding
>>>> behaviors. Further details can be found in X3D XML Encoding.
>>>>
>>>> * X3D4 Architecture, clause 19 Scripting component, 29.4.1 Script
>>>> *
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/scripting.html#Script
>>>>
>>>> * X3D4 Architecture, 9.2.3 Scripting language protocols
>>>>
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#ScriptingLanguageProtocols
>>>>
>>>> * X3D XML Encoding, Clause 4 Concepts, 4.3.13 Encapsulating Script node
>>>> code
>>>>
>>>> https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#EncapsulatingScriptNodeCode
>>>>
>>>> "If both a url field and a CDATA clause are encountered, the url
>>>> field is processed first. Thus, the CDATA construct can also be considered
>>>> equivalent to one additional value appended to the url MFString array. This
>>>> ordering allows an online script code url to take priority over fallback
>>>> default script code in the CDATA construct. This ordering also allows
>>>> run-time updates if a viewer is connected to the network, if so desired by
>>>> the originating author."
>>>>
>>>> ------
>>>>
>>>> 3. Next - naming. "CDATA" is pretty obscure as a field name,
>>>> especially since that is an XML datatype (for Character Data). Thus am
>>>> thinking "sourceCode" might be a better name... what do you think?
>>>>
>>>> The ability to embed safe scripting code within any X3D Script is a
>>>> powerful capability that also improves security possibilities for advanced
>>>> X3D... it is easier to secure and safely transport an embedded script than
>>>> it is to have multiple files handled safely.
>>>>
>>>> John, it looks like we already did something just like this in the JSON
>>>> encoding, we called it "sourceText", excerpt follows. (Excessive string
>>>> quoting was necessary to pass JSON parsing rules for multiline text.)
>>>>
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------
>>>> *
>>>> https://X3dGraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulator.json
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMaterialModulator.json&data=04%7C01%7Cbrutzman%40nps.edu%7Ca21361bf5da14489edc908d9d86dfc84%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637778789185932285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=IOpAF1lGWKRYlN5OO8Sl%2FT1S7Ed7MxBT6BocnOHxq4U%3D&reserved=0>
>>>>
>>>> { "Script":
>>>> {
>>>> [....]
>>>> "#sourceText":[
>>>> "",
>>>> "",
>>>> "ecmascript:",
>>>> "function initialize ()",
>>>> "{",
>>>> " newColor = diffuseColor; // start with original color",
>>>> "}",
>>>> "function clockTrigger (timeValue)",
>>>> "{",
>>>> " if (!enabled) return;",
>>>> " red = newColor.r;",
>>>> " green = newColor.g;",
>>>> " blue = newColor.b;",
>>>> "",
>>>> " // note different modulation rates for each color component, % is
>>>> modulus operator",
>>>> " newColor = new SFColor ((red + 0.02) % 1, (green + 0.03) % 1,
>>>> (blue + 0.04) % 1);",
>>>> "\tif (enabled)",
>>>> "\t{",
>>>> "\t\tBrowser.print ('diffuseColor=(' + red +',' + green + ',' + blue +
>>>> ') newColor=' + newColor.toString() + '\n');",
>>>> "\t}",
>>>> "}",
>>>> "function set_enabled (newValue)",
>>>> "{",
>>>> "\tenabled = newValue;",
>>>> "}",
>>>> "",
>>>> ""
>>>> ]
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------
>>>> Which in the .x3d XML CDATA simply looks like
>>>>
>>>> <Script DEF='MaterialModulatorScript'>
>>>> <field accessType='inputOutput' name='enabled' type='SFBool'/>
>>>> <field accessType='inputOutput' name='diffuseColor'
>>>> type='SFColor'/>
>>>> <field accessType='outputOnly' name='newColor'
>>>> type='SFColor'/>
>>>> <field accessType='inputOnly' name='clockTrigger'
>>>> type='SFTime'/>
>>>> <IS>
>>>> <connect nodeField='enabled' protoField='enabled'/>
>>>> <connect nodeField='diffuseColor'
>>>> protoField='diffuseColor'/>
>>>> </IS>
>>>> <![CDATA[
>>>> ecmascript:
>>>> function initialize ()
>>>> {
>>>> newColor = diffuseColor; // start with original color
>>>> }
>>>> function clockTrigger (timeValue)
>>>> {
>>>> if (!enabled) return;
>>>> red = newColor.r;
>>>> green = newColor.g;
>>>> blue = newColor.b;
>>>>
>>>> // note different modulation rates for each color component, % is
>>>> modulus operator
>>>> newColor = new SFColor ((red + 0.02) % 1, (green + 0.03) % 1, (blue
>>>> + 0.04) % 1);
>>>> if (enabled)
>>>> {
>>>> Browser.print ('diffuseColor=(' + red +',' + green +
>>>> ',' + blue + ') newColor=' + newColor.toString() + '\n');
>>>> }
>>>> }
>>>> function set_enabled (newValue)
>>>> {
>>>> enabled = newValue;
>>>> }
>>>> ]]>
>>>> </Script>
>>>>
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>> So this possibility is a cool prospect, again thanks for flagging it.
>>>> I'll work further on X3DUOM and Python, Java, OWL compatibility next.
>>>>
>>>> Have fun with X3D! 8)
>>>>
>>>> all the best, Don
>>>> --
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>> X3D graphics, virtual worlds, navy robotics https://
>>>> faculty.nps.edu/brutzman
>>>>
>>>> -----Original Message-----
>>>> From: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> Sent: Monday, January 10, 2022 6:37 PM
>>>> To: John Carlson <yottzumm at gmail.com>
>>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>; Brutzman,
>>>> Donald (Don) (CIV) <brutzman at nps.edu>
>>>> Subject: RE: Possible issue with X3dToPython.xslt, newly tested file
>>>> from X3D4WA: need x3d.py python support for Script CDATA
>>>>
>>>> Thanks for the interesting trouble report John.
>>>>
>>>> No changes needed to original X3D model, it passes all X3D Validator
>>>> tests (though X3D Schematron provides a few warnings).
>>>>
>>>> *
>>>> https://X3dGraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulator.x3d
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMaterialModulator.x3d&data=04%7C01%7Cbrutzman%40nps.edu%7Ca21361bf5da14489edc908d9d86dfc84%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637778789185932285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=PcRk1T5cpkV1jnuSTR2%2FdvaYOc%2BALUhOr%2FvKGwVvfDA%3D&reserved=0>
>>>> * https://savage.nps.edu/X3dValidator
>>>>
>>>> XMLSpy was stricter about type handling than our Java-based Saxon10
>>>> conversions for this example. XMLSpy diagnosed some problems that I fixed.
>>>>
>>>> After also fixing the stylesheet name provided by a diagnostic, all
>>>> X3dToPython.xslt changes were checked into subversion.
>>>>
>>>> I now get the following conversion error:
>>>>
>>>> =====================
>>>> create python:
>>>> C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors/Chapter14Prototypes//MaterialModulator.x3d
>>>> processing with X3dToPython stylesheet...
>>>> *** TODO x3d.py and X3dToPython.xslt need to handle embedded CDATA
>>>> source code for Script C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors/Chapter14Prototypes//MaterialModulator.py
>>>> self-validation tests...
>>>> validate python:
>>>> File "C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors\Chapter14Prototypes\MaterialModulator.py",
>>>> line 74
>>>> *** TODO x3d.py and X3dToPython.xslt need to handle embedded CDATA
>>>> source code for Script
>>>> ^
>>>> SyntaxError: invalid syntax
>>>> Result: 1
>>>> ===================================
>>>>
>>>> So, embedded CDATA scripting code inside a Script node (and similar
>>>> Shader nodes) remains an omission in our Python support.
>>>>
>>>> To remedy this, we need to create a special field in the X3DPSAIL class
>>>> Script. *What shall we call it?* Creating a Script member named CDATA
>>>> seems unambiguous and eponymous with the XML encoding...
>>>>
>>>> * X3D Tooltips, Script and Script url
>>>> https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Script
>>>> https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Script.url
>>>>
>>>> * X3D Tooltips, XML Data Types
>>>> https://www.web3d.org/x3d/tooltips/X3dTooltips.html#XML
>>>>
>>>> " CDATA is an XML term for Character Data. The base type for all XML
>>>> attributes consists of string-based CDATA characters. CDATA is used
>>>> throughout the X3D DOCTYPE definitions, which can only check for the
>>>> presence of legal strings and thus are not able to validate numeric type
>>>> information. XML Schema provides stricter validation based on data types."
>>>>
>>>> * XML, 2.4 Character Data and Markup
>>>> https://www.w3.org/TR/REC-xml/#syntax
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FREC-xml%2F%23syntax&data=04%7C01%7Cbrutzman%40nps.edu%7Ca21361bf5da14489edc908d9d86dfc84%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637778789185932285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hURgR6DMZ4HAQdimBlphKzMDVhWzG5zrz9bOkVb9y6Y%3D&reserved=0>
>>>>
>>>> all the best, Don
>>>> --
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>> X3D graphics, virtual worlds, navy robotics https://
>>>> faculty.nps.edu/brutzman
>>>>
>>>> -----Original Message-----
>>>> From: John Carlson <yottzumm at gmail.com>
>>>> Sent: Monday, January 10, 2022 4:06 PM
>>>> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics
>>>> public mailing list <x3d-public at web3d.org>
>>>> Subject: Possible issue with X3dToPython.xslt, newly tested file from
>>>> X3D4WA
>>>>
>>>> X3D XML file attached. From X3DJSONLD's maven build log:
>>>>
>>>> [INFO] --- xml-maven-plugin:1.0.2:transform (default) @ X3DJSONLD ---
>>>> [INFO] Transforming file:
>>>> /home/coderextreme/X3DJSONLD/src/main/data/MaterialModulatorExamples.x3d
>>>> [INFO] Transforming file:
>>>> /home/coderextreme/X3DJSONLD/src/main/data/MaterialModulator.x3d
>>>> Type error at char 37 in xsl:value-of/@select on line 610 column 120 of
>>>> X3dToPython.xslt:
>>>> XPTY0004: A sequence of more than one item is not allowed as the
>>>> first argument of
>>>> normalize-space() ("", "", ...)
>>>> at xsl:apply-templates
>>>>
>>>> (file:/home/coderextreme/X3DJSONLD/src/main/lib/stylesheets/X3dToPython.xslt#606)
>>>> processing /X3D/Scene[1]/ProtoDeclare[1]/ProtoBody[1]/Script[1]
>>>> at xsl:apply-templates
>>>>
>>>> (file:/home/coderextreme/X3DJSONLD/src/main/lib/stylesheets/X3dToPython.xslt#606)
>>>> processing /X3D/Scene[1]/ProtoDeclare[1]/ProtoBody[1]
>>>> at xsl:apply-templates
>>>>
>>>> (file:/home/coderextreme/X3DJSONLD/src/main/lib/stylesheets/X3dToPython.xslt#606)
>>>> processing /X3D/Scene[1]/ProtoDeclare[1]
>>>> at xsl:apply-templates
>>>>
>>>> (file:/home/coderextreme/X3DJSONLD/src/main/lib/stylesheets/X3dToPython.xslt#606)
>>>> processing /X3D/Scene[1]
>>>> at xsl:apply-templates
>>>>
>>>> (file:/home/coderextreme/X3DJSONLD/src/main/lib/stylesheets/X3dToPython.xslt#123)
>>>> processing /X3D
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] BUILD FAILURE
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] Total time: 2.840 s
>>>> [INFO] Finished at: 2022-01-10T17:59:22-06:00 [INFO]
>>>> ------------------------------------------------------------------------
>>>> [ERROR] Failed to execute goal
>>>> org.codehaus.mojo:xml-maven-plugin:1.0.2:transform (default) on project
>>>> X3DJSONLD: Failed to transform input file
>>>> /home/coderextreme/X3DJSONLD/src/main/data/MaterialModulator.x3d: A
>>>> sequence of more than one item is not allowed as the first argument of
>>>> normalize-space() ("", "", ...) -> [Help 1] [ERROR] [ERROR] To see the
>>>> full stack trace of the errors, re-run Maven with the -e switch.
>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>> [ERROR]
>>>> [ERROR] For more information about the errors and possible solutions,
>>>> please read the following articles:
>>>> [ERROR] [Help 1]
>>>>
>>>> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FMAVEN%2FMojoExecutionException&data=04%7C01%7Cbrutzman%40nps.edu%7C79b6d0212127425f31b408d9d4ab3773%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637774654099751000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VYVojdsW4QsyjrkZGnqfPOPmUp7x5ftTGE3H0TzrTts%3D&reserved=0
>>>> <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FMAVEN%2FMojoExecutionException&data=04%7C01%7Cbrutzman%40nps.edu%7Ca21361bf5da14489edc908d9d86dfc84%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637778789185932285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GEjKI%2BOCI%2FfcHC9D6D%2BZgZ4o4TF9GKL%2FJYEyyCHQ8fs%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220115/69234d24/attachment-0001.html>
More information about the x3d-public
mailing list