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

[Andreas Plesch]

Another idea may be to put the containerField attribute to work, as it has
a similar function. Only with extension metadata, it would mean to use the
value not the whole node as field value.


<Shape bboxDisplay='true'>
       <MetadataFloat name='extension' containerfield='bboxColor' value='
"0.7 0.8 0.9" '/>
       <MetadataFloat name='extension' containerfield='bboxMargin' value='
"0.1" ' />
     <Sphere/>
</Shape>

Finally, for validation purposes, an extensiion vocabulary could be used in
a reverse fashion by removing known extension fields first from a x3d
document and then doing regular validation.

Andreas

---on the phone---

On Sun, Apr 2, 2023, 12:27 AM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
wrote:

> Excellent catch regarding MetadataDouble, thanks Holger.
>
> Andreas, for full-fledged node definitions, we might also use an extension
> schema and DTD for native expression.
>
> Also of interest is that each Metadata* node (such as MetadataDouble)
> includes  the 'reference' field which can include further information, such
> as an author description or url link.
>
> v/r Don
>
> -----Original Message-----
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Saturday, April 1, 2023 7:48 PM
> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> Cc: Michalis Kamburelis <michalis.kambi at gmail.com>; Holger Seelig <
> holger.seelig at yahoo.de>; Doug Sanden <gpugroup at gmail.com>; x3dom mlist <
> x3dom-users at lists.sourceforge.net>; X3D <x3d-public at web3d.org>
> Subject: Re: [x3dom-users] [x3d-public] bboxDisplay considerations;
> metadata nodes for new field extensions
>
> NPS WARNING: *external sender* verify before acting.
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230402/515bf42a/attachment-0001.html>