[x3d-public] x3d extensions through Metadata

[Andreas Plesch]

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