<div dir="auto">I think the language name for “bi-directional routes” is called two way binding:<div><a href="https://stackoverflow.com/questions/45490004/2-way-data-binding-in-javascript">https://stackoverflow.com/questions/45490004/2-way-data-binding-in-javascript</a></div><div dir="auto"><br></div><div dir="auto">N-way would be interesting!</div><div dir="auto"><br></div><div dir="auto">John </div><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 3, 2023 at 1:49 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">While Metadata could provide a backward compatible way to represent<br>
non-standard fields and nodes, it seems difficult to use such Metadata<br>
nodes for events and routes.<br>
<br>
It would mean for a browser to establish implicit, internal<br>
bi-directional routes between an extension Metadata node and the<br>
actual field of a scene graph node. This becomes similar to Prototypes<br>
and quite difficult to track properly for a browser.<br>
<br>
A potential solution may be to disregard extension Metadata nodes for<br>
routing to the represented nodes. Extension Metadata nodes would only<br>
be used initially to populate extension fields and add extension nodes<br>
to the scene graph.<br>
<br>
In effect this means that for MetadataSets representing SFNodes it<br>
will be necessary to include another MetadataString child which<br>
defines the DEF name of the represented extension node. So the name<br>
for this MetadataString could be 'DEFname' and the value the name<br>
which can be used for routing. Unfortunately, it would not be possible<br>
to use the name field of the MetadataSet since the name field contains<br>
the node name ("Depthmode"). It is also not possible to use the DEF<br>
statement because it will refer to the Metadata node, not the<br>
represented SFNode.<br>
<br>
This way there is complete information to construct the scene graph<br>
node during first loading and add it.<br>
<br>
This also would mean routes with a fromNode or toNode to an extension<br>
node with a DEFname of say "readonlyDepthmask" represented by a<br>
MetadataSet would be legal even although there is no DEF statement<br>
with such a name, only the corresponding MetadataString. If validators<br>
check for routes, they would have to account for this.<br>
Similarly routes with fromField or toField to an extension field, say<br>
"sortKey", would be also legal although the field is only represented<br>
by MetadataXXX node with the name of the field.<br>
<br>
Perhaps this all means that the integrity of routes cannot be<br>
completely validated if Metadata are used to represent extension<br>
fields and nodes.<br>
<br>
It is probably time to put together examples for easier discussion.<br>
<br>
-Andreas<br>
<br>
On Sun, Jul 2, 2023 at 1:45 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> X3D Browsers may have non-standard extensions such as fields and<br>
> nodes. It has been suggested that a backwards compatible way to access<br>
> such extensions could be accomplished through Metadata nodes. This way<br>
> a X3D file using such extensions still can conform strictly to the<br>
> syntactic standard.<br>
><br>
> It should be possible for browsers to have general and automatic<br>
> recognition of such extension fields and nodes provided in Metadata.<br>
> Here is a first draft mechanism:<br>
><br>
> A metadata node would advertise that it is eligible to be considered<br>
> as an extension, probably through a reference value of say<br>
> "x3dExtension", or by being contained in a special Metadataset with<br>
> such a name or reference.<br>
><br>
> Then a browser would check the Metadata name and if the name is<br>
> equivalent to an implemented field of the parent node, the browser<br>
> would use the value of the Metadata and use it in some way as the<br>
> value of the field (This could also apply to standard fields).<br>
><br>
> Since Metadata values can only be of type MFString, MFFloat, MFDouble,<br>
> MFBool or MFInt32 there needs to be some translation to field values.<br>
><br>
> Most translations are obvious but SF/MFNode fields are not. One option<br>
> is to provide the xml string of an SFNode as the value in a<br>
> MetadataString node. But this may be too encoding specific. On the<br>
> other hand there is the standard SAI  function createX3DFfromString<br>
> for that.<br>
><br>
> So another option is to use MetadataSet for SFNode. name would still<br>
> be the field name for the SFNode. Then the children of MetadataSet<br>
> would contain the fields of the SFNode node. In addition there would<br>
> be a MetadataString node with name "nodeName" which has the node name<br>
> as the value.  This is more verbose but crosses encodings.<br>
><br>
> MFNode fields would also use MetadataSet. The only children would be<br>
> MetadataSet of the SFNode kind.<br>
><br>
> I will have to check how well that kind of mechanism would fit with<br>
> processing of metadata in x3dom. It may not fit that well.<br>
><br>
> Any feedback, or ideas welcome,<br>
><br>
> Andreas<br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>