[x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible

Mon Jul 3 16:05:22 PDT 2023

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 <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)
> <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
> 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: x3d-public <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 <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 <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
> >
> > x3d-public at web3d.org
> >
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> 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/20230703/8897e0ab/attachment-0001.html>