[x3d-public] [x3dom-users] bboxDisplay considerations; metadata nodes for new field extensions

[Andreas Plesch]

I misremembered. In fact, all Metadata types hold MF values. But it
still seems very verbose to have a Metadata node for each field.
For validation of extension fields a vocabulary would still be needed
and have the actual field type like SFColor.

An extension node value could look like:

<MetadataSet name="extension-node">
  <MetadataString name="node-name" value=' "BinaryGeometry" ' />
  <MetadataString name="node-fields" value=' "url=\' \"datafile.dat\"
\' "  "primitiveMode=\'LINES\'" ...  ' />
</MetadataSet>

or simply
<MetadataString name="extension-node" value=' "\<BinaryGeometry\>"
"url=\' datafle.dat\' " "primitiveMode=\'LINES\'" ... ' />

Parsing is harder, but hopefully schematron/xslt/xpath would be
sufficiently expressive to allow the verbosity.be at a minimum.

Some ideas,

Andreas

On Sat, Apr 1, 2023 at 5:41 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Hi Don,
>
> Using metadata as an extension mechanism may be feasible. It would
> require more thought on how to represent non-standard nodes in
> metadata in addition to fields. For example, x3dom has the popular
> BinaryGeometry node.
>
> The metadata seem quite verbose. It would probably suffice to have a
> single MetaDataMFString with all non-standard attributes:
>
> <Shape bboxDisplay='true'>
>    <MetadataString name='extension-fields' value=' " bboxColor=\'0.7
> 0.8 0.9\' " "bboxMargin=\'0.1\' " />
>    <Sphere/>
> </Shape>
>
> Instead of the "=" sequential name-value pairs may be preferable. The
> meaning would be "add to the node as attribute name-value pairs in xml
> encoding before initial parsing".
>
> This makes parsing a bit harder but since MFtypes can generally only
> be represented as strings in Metadata, such parsing is necessary in
> any case.
> For x3dom, the metadata values would only be used for initialization of fields.
>
> Another way to think about validation of non-standard extensions is to
> actually provide custom validation for such documents. This seems hard
> but perhaps could be accomplished with a plug-in system for a base
> validator system. Plug-ins could then be provided by extension
> authors.
>
> Finally, it is not unreasonable to keep the current semantics of
> validation. Adding non-standard fields and nodes invalidates a
> document.
>
> Best, Andreas
>
> On Sat, Apr 1, 2023 at 3:57 PM Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu> wrote:
> >
> > Thanks for continuing news about this excellent progress.
> >
> > Am thinking we might all agree to regularize addition of nonstandard fields in a way that still passes content validation.
> >
> > For example, non-standard experimental example
> >
> > <Shape bboxDisplay='true' bboxColor='0.7 0.8 0.9' bboxMargin='0.1' >
> >    <Sphere/>
> > </Shape>
> >
> > Might be equivalently and validly expressed as
> >
> > <Shape bboxDisplay='true'>
> >    <MetadataSet name='extension'>
> >         <MetadataString name='bboxColor' value='0.7 0.8 0.9'/>
> >         <MetadataString name='bboxMargin' value='0.1' />
> >    </MetadataSet>
> >    <Sphere/>
> > </Shape>
> >
> > A little more verbose perhaps... However, note that not only is model content validatable, but metadata content might also be validated if we build a metadata vocabulary that lists experimental field names, types and default values.  That way common extensions might be more sharable and model content remains confirmably correct.
> >
> > Seems like a useful good practice that isn't complex, so we could easily build <MetadataSet name='extension'> capabilities into our browser parsers and authoring tools.
> >
> > The X in X3D is Extensible... looking forward to continued innovation and practice/progress together.
> >
> > v/r Don
> >
> >
> > -----Original Message-----
> > From: Andreas Plesch <andreasplesch at gmail.com>
> > Sent: Saturday, April 1, 2023 6:43 AM
> > To: X3D <x3d-public at web3d.org>
> > Cc: x3dom mlist <x3dom-users at lists.sourceforge.net>
> > Subject: Re: [x3dom-users] [x3d-public] bboxDisplay considerations
> >
> > The bboxDisplay field is now available for bounded objects (grouping nodes and shapes) in the dev. version of x3dom.
> >
> > The color of the displayed bounding box can be customized with the non-standard bboxColor field, and the size expanded with the bboxMargin field.
> >
> > Enjoy ! Andreas
> >
> > On Thu, Mar 30, 2023 at 2:19 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >
> > > I think it will be very useful to allow different colors for different
> > > sets of bounding boxes. Here are the rotating cubes with two sets of
> > > bounding boxes. The yellow ones react to a TouchSensor, the orange
> > > ones do not:
> > > [...]
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453