[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 16:49:55 PST 2022
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/d1dd0409/attachment-0001.html>
More information about the x3d-public
mailing list