[x3d-public] x3d extensions through Metadata

[John Carlson]

I think the language name for “bi-directional routes” is called two way
binding:
https://stackoverflow.com/questions/45490004/2-way-data-binding-in-javascript

N-way would be interesting!

John


On Mon, Jul 3, 2023 at 1:49 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230705/d1bc2481/attachment.html>