[x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Tue Jul 4 09:40:01 PDT 2023
Yes interesting. Good to know where the horizon of effectiveness lies (rather than tumbling over outer boundaries).
In general, I don’t think renaming core nodes is a good practice. Too prone to misinterpretation and misunderstanding, too difficult to validate, fails mysteriously when out of context. Key approach in XML and Semantic Web is use of namespaces, explicitly defining context instead of permitting overloaded ambiguity.
Our team’s heuristic for naming conventions comes from Jeff Weekley,
* X3D Scene Authoring Hints: Naming Conventions
* (Ironic) Success Metric: when is a name successful?
Answer: when no one has to discuss that name any more, it is simply understood.
* https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions
Even more fundamentally:
* Wikipedia, David Wheeler
* https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist)#Quotes
* Wheeler is often quoted as saying "All problems in computer science can be solved by another level of <https://en.wikipedia.org/wiki/Indirection> indirection." <https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist)#cite_note-26> [26] or "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection." <https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist)#cite_note-27> [27] This has been called the <https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering> fundamental theorem of software engineering.
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: Andreas Plesch <andreasplesch at gmail.com>
Sent: Monday, July 3, 2023 7:47 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: GPU Group <gpugroup at gmail.com>; X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible
Hi Don,
This method works if adding a new extension field to an existing node also means defining a new node. In the example 'MaterialModulator' is the new name for what was the Material node. However, the task is to add a new field to an existing node without changing its name. This is the difference between an extension adding a field and an extension defining a new node.
Using ProtoDeclare would work for this if it would be allowed to reuse an existing node name, here Material. But this is likely not allowed since it could lead probably to cyclic redefinitions.
An idea may be to actually require use of an existing node name for a special extension ExternProtoDeclare statement. Extension ExternProtoDeclare statement could identify themselves with a special url value or urn. Such extension ProtoDeclare statements would not have a Protobody.
Example:
<ExternProtoDeclare name="Appearance" url='"x3d_field_extension"'> <field name='material'
type='SFNode'
accessType='inputOutput'/><field name='material'
type='SFNode'
accessType='inputOutput'/>
<field name='acousticProperties'
type='SFNode'
accessType='inputOutput'/>
...(many more}
<field name='sortKey'
type='SFFloat'
accessType='initializeOnly'/> </ExternProtoDeclare>
(Still need a default value for the new field somehow)
and
<Shape>
<ProtoInstance name="Appearance">
<fieldValue name='sortKey' value='1'/>
<fieldValue name='material'>
<Material />
</fieldValue>
</ProtoInstance>
<Box/>
<Shape>
alongside regular Appearance
<Shape>
<Appearance>
<Material />
</Appearance>
<Box/>
<Shape>
This seems pretty ugly and hard to process compared to a simple Metadata node, appended. So this does not seem to be the solution.
Perhaps there are other ideas, Andreas
On Mon, Jul 3, 2023 at 9:35 PM Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu> wrote:
>
> Acknowledged all, thanks.
>
>
>
> The way to use a prototype to only extend the fields in a node is to declare a new prototype node containing the original node as first node, include the original fields with IS connections (as appropriate) then add new fields of interest.
>
>
>
> Example follows, preserving original fields and adding an ‘enabled’ field.
>
>
>
> X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14
> Prototypes, Material Modulator Mimic a Material node and modulate the diffuseColor field as an animation effect, provided as a prototype for reusability.
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> rialModulatorIndex.html&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd04678e
> 08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63
> 8240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=mBBcdr8a%2
> FU%2BPiW1ziMOnVdpZuHYd30eLR9ChAvmfLGc%3D&reserved=0
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> rialModulator.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd04678e08441e
> de2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63824035
> 7204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X9iYcy9GCO5z8zqg
> RoQ2XKMiWnFJA1pOAzA9KauptCo%3D&reserved=0
>
>
>
> X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14
> Prototypes, Material Modulator Examples Demonstrate multiple instances of an external prototype.
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> rialModulatorExamplesIndex.html&data=05%7C01%7Cbrutzman%40nps.edu%7C31
> fd04678e08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%
> 7C0%7C638240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Wv
> iNgBQYwXBhmVlrgu%2FrhsB9DLT3lrzA%2FpFSJ8NSK48%3D&reserved=0
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> rialModulatorExamples.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd0467
> 8e08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C
> 638240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=IIdrmmI7
> kpyk%2FSWq4et75LqyjDZWr8R1G9h6yjyZ0KE%3D&reserved=0
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> 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> https://faculty.nps.edu/brutzman
>
>
>
> From: GPU Group < <mailto:gpugroup at gmail.com> gpugroup at gmail.com>
> Sent: Monday, July 3, 2023 4:05 PM
> To: Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com>
> Cc: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>; X3D Graphics
> public mailing list < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
> Subject: Re: [x3d-public] x3d extensions through Metadata;
> ExternProtoDeclare also possible
>
>
>
> Tangentially related:
>
> a) tuple nodes in web3d: like script or protoDeclare fields - configurable field types, but that's all it is - a collection of fields.
>
> - and can be ROUTEd as SFNodes
>
> b) Blender import - where to hide non-blender nodes and information,
> in such a way they can be exported and reconstituted in the exported
> scene
>
> -Doug
>
>
>
> On Mon, Jul 3, 2023 at 3:46 PM Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
>
> Hi Don,
>
> <MetadataSet name="NewFields4.1" containerField='metadata'><!—list of
> fields follow --></MetadataSet> would work. On the other hand, I may
> prefer use of the reference field to avoid a level of hierarchy:
>
> <MetadataFloat reference="NewFields4.1" name="sortKey" value="1"
> containerField='metadata' />
>
> After all, reference is supposed to be used for a well-defined class
> of Metadata, perhaps with a Schema.
>
> We should keep in mind that there will be extensions which are not
> candidates for v4.1.
>
> Describing the SFNode representation, I also had thought about reusing
> ProtoInstance, with or without ProtoExternDeclare. But how would one
> then represent extension fields to existing nodes like Shape ?
>
> I guess it is possible to mix and match Metadata and Proto but it
> seems not ideal.
>
> Best, Andreas
>
>
> On Mon, Jul 3, 2023 at 3:48 PM Brutzman, Donald (Don) (CIV)
> < <mailto:brutzman at nps.edu> brutzman at nps.edu> wrote:
> >
> > Good efforts, thanks for thinking this possibility through farther.
> > Agreed that new fields might be added this way
> >
> > <MetadataSet name="NewFields4.1" containerField='metadata'><!—list of fields follow --></MetadataSet> though nodes do seem trickier.
> >
> >
> >
> > Another thought, belatedly: we might also use more-familiar ExternProtoDeclare constructs to define signatures for any new nodes of interest.
> >
> >
> >
> > While we usually work hard to provide essential implementations in X3D for such declarations (possibly including even Script and Shader nodes), it is also possible that an X3D browser might recognize particular externproto nodes of interest and apply its own native implementation. The ExternProtoDeclare might even point to a stub that let any player read and handle them without rendering or error.
> >
> >
> >
> > Then including a ProtoInstance for each usage of each new node also has familiar, simple syntax.
> >
> >
> >
> > all the best, Don
> >
> > --
> >
> > Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> 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> https://faculty.nps.edu/brutzman
> >
> >
> >
> > -----Original Message-----
> > From: x3d-public < <mailto:x3d-public-bounces at web3d.org> x3d-public-bounces at web3d.org> On Behalf Of Andreas
> > Plesch
> > Sent: Monday, July 3, 2023 11:51 AM
> > To: X3D Graphics public mailing list < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
> > Subject: Re: [x3d-public] x3d extensions through Metadata
> >
> >
> >
> > While Metadata could provide a backward compatible way to represent non-standard fields and nodes, it seems difficult to use such Metadata nodes for events and routes.
> >
> >
> >
> > It would mean for a browser to establish implicit, internal bi-directional routes between an extension Metadata node and the actual field of a scene graph node. This becomes similar to Prototypes and quite difficult to track properly for a browser.
> >
> >
> >
> > A potential solution may be to disregard extension Metadata nodes for routing to the represented nodes. Extension Metadata nodes would only be used initially to populate extension fields and add extension nodes to the scene graph.
> >
> >
> >
> > In effect this means that for MetadataSets representing SFNodes it will be necessary to include another MetadataString child which defines the DEF name of the represented extension node. So the name for this MetadataString could be 'DEFname' and the value the name which can be used for routing. Unfortunately, it would not be possible to use the name field of the MetadataSet since the name field contains the node name ("Depthmode"). It is also not possible to use the DEF statement because it will refer to the Metadata node, not the represented SFNode.
> >
> >
> >
> > This way there is complete information to construct the scene graph node during first loading and add it.
> >
> >
> >
> > This also would mean routes with a fromNode or toNode to an extension node with a DEFname of say "readonlyDepthmask" represented by a MetadataSet would be legal even although there is no DEF statement with such a name, only the corresponding MetadataString. If validators check for routes, they would have to account for this.
> >
> > Similarly routes with fromField or toField to an extension field, say "sortKey", would be also legal although the field is only represented by MetadataXXX node with the name of the field.
> >
> >
> >
> > Perhaps this all means that the integrity of routes cannot be completely validated if Metadata are used to represent extension fields and nodes.
> >
> >
> >
> > It is probably time to put together examples for easier discussion.
> >
> >
> >
> > -Andreas
> >
> >
> >
> > On Sun, Jul 2, 2023 at 1:45 PM Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
> >
> > >
> >
> > > X3D Browsers may have non-standard extensions such as fields and
> >
> > > nodes. It has been suggested that a backwards compatible way to
> > > access
> >
> > > such extensions could be accomplished through Metadata nodes. This
> > > way
> >
> > > a X3D file using such extensions still can conform strictly to the
> >
> > > syntactic standard.
> >
> > >
> >
> > > It should be possible for browsers to have general and automatic
> >
> > > recognition of such extension fields and nodes provided in Metadata.
> >
> > > Here is a first draft mechanism:
> >
> > >
> >
> > > A metadata node would advertise that it is eligible to be
> > > considered
> >
> > > as an extension, probably through a reference value of say
> >
> > > "x3dExtension", or by being contained in a special Metadataset
> > > with
> >
> > > such a name or reference.
> >
> > >
> >
> > > Then a browser would check the Metadata name and if the name is
> >
> > > equivalent to an implemented field of the parent node, the browser
> >
> > > would use the value of the Metadata and use it in some way as the
> >
> > > value of the field (This could also apply to standard fields).
> >
> > >
> >
> > > Since Metadata values can only be of type MFString, MFFloat,
> > > MFDouble,
> >
> > > MFBool or MFInt32 there needs to be some translation to field values.
> >
> > >
> >
> > > Most translations are obvious but SF/MFNode fields are not. One
> > > option
> >
> > > is to provide the xml string of an SFNode as the value in a
> >
> > > MetadataString node. But this may be too encoding specific. On the
> >
> > > other hand there is the standard SAI function
> > > createX3DFfromString
> >
> > > for that.
> >
> > >
> >
> > > So another option is to use MetadataSet for SFNode. name would
> > > still
> >
> > > be the field name for the SFNode. Then the children of MetadataSet
> >
> > > would contain the fields of the SFNode node. In addition there
> > > would
> >
> > > be a MetadataString node with name "nodeName" which has the node
> > > name
> >
> > > as the value. This is more verbose but crosses encodings.
> >
> > >
> >
> > > MFNode fields would also use MetadataSet. The only children would
> > > be
> >
> > > MetadataSet of the SFNode kind.
> >
> > >
> >
> > > I will have to check how well that kind of mechanism would fit
> > > with
> >
> > > processing of metadata in x3dom. It may not fit that well.
> >
> > >
> >
> > > Any feedback, or ideas welcome,
> >
> > >
> >
> > > Andreas
> >
> > > --
> >
> > > Andreas Plesch
> >
> > > Waltham, MA 02453
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Andreas Plesch
> >
> > Waltham, MA 02453
> >
> >
> >
> > _______________________________________________
> >
> > x3d-public mailing list
> >
> > <mailto:x3d-public at web3d.org> x3d-public at web3d.org
> >
> > <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> <mailto:x3d-public at web3d.org> x3d-public at web3d.org
> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230704/b5aa5ca5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230704/b5aa5ca5/attachment-0001.p7s>
More information about the x3d-public
mailing list