[x3d-public] Extending beyond short form to dependency/module management
John Carlson
yottzumm at gmail.com
Sat May 10 16:11:42 PDT 2025
XML Proto “short form” really reminds me of creating new functions/methods
or data/class structures. Yes, there’s a danger of overriding in some
languages, but many languages provide some kind of warning or failure.
Perhaps we should consider an X3D Scene file a “module” and we already have
Inline, etc. of such modules. The key here is *versioning* Inlines,
PROTOs, erc.
What I haven’t seen is a way to version an X3D module—source code
repositories non-withstanding. Yes, the standards have versions. We need
a way to include different versions of modules and provide hierarchies of
acceptable module versions that work together. Dependency systems are now
highly mature. I’ve used Maven, Gradle, Npm, and now there’s a “maturer”
TypeScript module system in JSR. Others are familiar with pip and
requirements.txt files.
I’m pretty sure that none of VRML, HTML nor XML files have dependency
management systems. Maybe it’s time for a standards body to look at that.
I do know that JavaScript is advancing to provide JSON files on import, and
the file can be versioned AFAIK, with typical JavaScript package/dependency
management. I’ve not used that feature.
Yes, I realize they are a pain in the but, but perhaps we can specify
dependencies with Metadata* nodes, instead of coming up with a new standard
node. But my preference would be to come up with a MetadataVersion node
which uses other Metadata* nodes. Or just claim that Metadata nodes
without a name field default to name=“version”. This seems like a very
small update to the standard.
So the metadata version attached to a PROTO or Inline could direct a build
system to download a file from an web3d or other repository, much like URLs
are done today. Often the URL will contain the version. The point is to
cache it on the system in case the network goes down! I’m sure we’ve
probably all experienced downed networks or airplane rides where you’re
missing a file.
So now we come full circle to keep URLs to local files present. But with
no way to update all your URLs to the most recent version of the file, just
like we have to keep URL versions up to date in HTML files. That’s what
package management systems were built to fix.
I’m stuck and out of time for now. Looking for a way out of dependency
hell.
John
On Sat, May 10, 2025 at 5:15 PM John Carlson <yottzumm at gmail.com> wrote:
> My recall is that new node types were “registered” and one could not
> declare new PROTOs with the same name. This was problematic when wanting
> to reload a file. Perhaps some sort of versioning is indicated.
>
> As for Schema, both in JSON and XML, couldn’t we create a barebones schema
> or X3DUOM from a ProtoDeclare? What additional field attributes might be
> required?
>
> Then the task would be modifying the Schema DOM or JavaScript Schema
> object? Obviously kind of dangerous, but no more dangerous than web
> components?
>
> Hmm!
>
> John
>
> On Sat, May 10, 2025 at 11:38 AM Brutzman, Donald (Don) (CIV) via
> x3d-public <x3d-public at web3d.org> wrote:
>
>> Thanks for the interesting, innovative discussion. Excerpting the
>> example:
>>
>>
>> -
>> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>>
>>
>> _________________________
>> XML Encoding
>>
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>> 7
>> 8
>> 9
>>
>> <!--* Official Syntax *-->
>> <ProtoInstance name='BouncingBall'>
>> <fieldValue name='cycleInterval' value='2'/>
>> <fieldValue name='bounceHeight' value='3'/>
>> </ProtoInstance>
>> <!-- *Short Syntax *-->
>> <BouncingBall
>> cycleInterval='2'
>> bounceHeight='3'/>
>>
>> Classic VRML Encoding
>>
>> 1
>> 2
>> 3
>> 4
>>
>> BouncingBall {
>> cycleInterval 2.0
>> bounceHeight 3.0
>> }
>>
>> _________________________
>>
>> One drawback with the "short" XML syntax is that it will not pass XML
>> DOCTYPE or XML Schema validation, although it still must conform to XML
>> well-formed rules. Additional tool-specific capabilities can check for
>> such correctness during parsing, of course. Avoiding XML validation
>> relaxes quality assurance (QA) for the entire scene, not just that
>> prototype instance, and so use of the short form should be considered
>> carefully.
>>
>> Of course there is much merit too, not least of which are readability and
>> consistency with other XML-encoded nodes.
>>
>> As it turns out, now is a good time to consider such a change to the X3D
>> Standards suite. We have highly mature documents defining X3D encodings
>> using XML and ClassicVRML syntax. Conceivably a "short" form for
>> ProtoInstance will carry over satisfactorily for JSON and other encodings
>> as well, when we get to them this fall.
>>
>> If X_ITE and X3DOM already handle this form, and if Castle Model Viewer
>> (Castle Game Engine) is also supportive, I'm not yet seeing any blockers to
>> adoption. Further implementation and evaluation of course will be useful
>>
>> Reference and specific clause that would need modification:
>>
>>
>> - *X3D XML Encoding 4.0
>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/X3D_XML.html>*
>> revision 19776-1
>> - 4.3.3.2 ProtoInstance node and fieldValue statement syntax
>> -
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/concepts.html#ProtoInstanceAndFieldValueStatement
>>
>>
>> Probably no changes needed:
>>
>>
>> - *X3D Classic VRML Encoding 4.0
>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/X3D_ClassicVRML.html>*
>> revision 19776-2
>> - 4.3.3.2 Prototype instances and field value initialization syntax
>> -
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/concepts.html#ProtoInstanceAndFieldValueStatement
>>
>> - *X3D Architecture 4.1
>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/Architecture.html>*,
>> revision 19775-1
>> - 4.4.4 Prototype semantics
>> -
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#PrototypeSemantics
>>
>>
>> Thanks for careful consideration of this potential capability. All
>> feedback welcome.
>>
>> Have fun with X3D extensibility! 🙂
>>
>> 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 on behalf of Holger Seelig via x3d-public
>> *Sent:* Saturday, May 10, 2025 1:13 AM
>> *To:* X3D
>> *Cc:* Holger Seelig
>> *Subject:* Re: [x3d-public] Simplifying ProtoInstance nodes
>>
>> This is already possible if you use the „short syntax“ of a proto
>> instance:
>>
>>
>> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>>
>> You can use this in X_ITE, but also in X3DOM.
>>
>> Best regards,
>> Holger
>>
>> --
>> Holger Seelig
>> Leipzig, Germany
>>
>> holger.seelig at yahoo.de
>> https://create3000.github.io/x_ite/
>> https://patreon.com/X_ITE
>>
>>
>>
>> Am 10.05.2025 um 05:55 schrieb John Carlson via x3d-public <
>> x3d-public at web3d.org>:
>>
>> My thought is to replace “ProtoInstance” tags with “MenuItem” tags, and
>> fieldValue statements with attributes, but I’ve not done that before. My
>> goal is to make the model more accessible to screen readers.
>>
>> Any examples are welcome.
>>
>> See attached link and model.
>>
>> John
>>
>> ---------- Forwarded message ---------
>> From: *John Carlson* <yottzumm at gmail.com>
>> Date: Thu, Mar 6, 2025 at 4:35 PM
>> Subject: Latest cleaned Jin FACS (needs metadata)
>> To: Don Brutzman <brutzman at nps.edu>, Joe D Williams <
>> joedwil at earthlink.net>
>>
>>
>> Attached.
>>
>> And:
>>
>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d
>>
>> John
>> <CleanedYouClocks.x3d>_______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> _______________________________________________
>> 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/20250510/ce3d9225/attachment-0001.html>
More information about the x3d-public
mailing list