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

Mon Apr 3 01:18:11 PDT 2023

Consider using something like an HTML list with CSS display: false instead
of MFStrings.

Metadata may fit that, if used properly.

Thanks,

John

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

> Sorry but applying special purposes to containerField won't work - we must
> retain equivalent expressiveness across all of the various file encodings
> for X3D.  Such correspondences exist already, so we want to use them in
> these extensibility matters as well.  Further there is already a bunch of
> careful handling of containerField in XML validation tools in place
> already, so we don’t want to poke that complex-and-properly-working pile of
> code when unnecessary.  Functional summary:
>
>
>
>    - X3D Scene Authoring Hints: containerField
>    -
>    https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
>
>
>
> Helpful reference, thanks.  Yes we will be able to add experimental schema
> and DTD extensions someday, just as we did when transitioning from earlier
> versions of X3D.  Life after 4.0 !  8)
>
>
>
> v/r Don
>
>
>
> -----Original Message-----
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Sunday, April 2, 2023 9:42 AM
> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> Cc: Holger Seelig <holger.seelig at yahoo.de>; Michalis Kamburelis <
> michalis.kambi at gmail.com>; 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
>
>
>
>
>
> Yes, the containerfield idea would require a tweaking of the rules, for
> the special case of an extension metadata set (and contained children).
> Perhaps worth the change in rules since the extension metadata set would be
> special functionally, eg. require a change in the rules of how to interpret
> metadata.
>
>
>
>
> https://stackoverflow.com/questions/3392402/how-do-i-extend-a-base-schema-with-custom-elements-while-remaining-open-to-chang
>
> has a few strategies to provide extension plugins for a base validation
> schema.
>
>
>
> Draconian extension validation may be possible with such plugins.
>
>
>
> Scrubbing could have its own reporting ?
>
>
>
> x3dom is lenient, accepts any unrecognized attributes or elements by
> ignoring, and then only logs a message.
>
>
>
> Andreas
>
>
>
> On Sun, Apr 2, 2023 at 12:14 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> >
>
> > Interesting containerField-example approach, but…
>
> >
>
> >
>
> >
>
> > containerField describes relationship of a given node to its parent
> node.  So allowed values are either ‘metadata’ (in most cases) or ‘value ’
> (when parent node is a MetadataSet node).  Thus can’t be repurposed as
> shown by this example.
>
> > containerField is only used in XML-encoded model files, and typically
> unnecessary through use of default node-specific values.  Those values are
> used explicitly in other encodings (ClassicVrml, JSON, etc.) which have
> identical expressive power.  Thus such an approach would not be portable.
>
> > Generally each node in X3D is only allowed a single Metadata child.
> Thus if you need 2 MetadataFloat nodes, you will need a single parent
> MetadataSet between them and the containing node.
>
> > p.s. No additional interior quote marks or brackets when using
> MetadataDouble, MetadataFloat etc.
>
> >
>
> >
>
> >
>
> > Good point about scrubbing experimental fields before validation,
> agreed.  Test results might be tricky to report at that point, but if we
> have an agreed-upon set of extensions then browsers might be extra lenient
> when encountering recognized-but-unsupported fields.
>
> >
>
> >
>
> >
>
> > Nevertheless I’d imagine that lenient (non-draconian) X3D players do
> such user-friendly scrubbing during parsing most of the time anyway,
> reporting warnings/errors but nevertheless proceeding with rendering if
> possible.  XML validation requires draconian parse, but showstopper
> validation is not a requirement for rendering (though it is a helpful user
> preference, and some failures can be considered showstoppers).  Tradeoff
> arguments should be considered by each application.
>
> >
>
> >
>
> >
>
> > Postel’s law – Robustness principle
>
> > "be conservative in what you do, be liberal in what you accept from
> others"
>
> > https://en.wikipedia.org/wiki/Robustness_principle
>
> >
>
> >
>
> > X3D Metadata references:
>
> >
>
> >
>
> >
>
> > X3D for Web Authors (X3D4WA), online chapter 15, Metadata Information
>
> >
> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter15-Metadata/Chapter15-MetadataInformation.html
>
> >
>
> >
>
> > X3D4 Architecture, Core Component
>
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.review/Part01/components/core.html
>
>
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr
> oof/Part01/components/core.html
>
> >
>
> >
>
> >
>
> > Shape node, XML validation, Schema and DOCTYPE
>
> > https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_Shape.html#Link1D7
>
>
> > https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#S
> hape
>
> >
>
> >
>
> >
>
> > X3D Tooltips, Metadata* nodes
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataBoolean
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataDouble
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataFloat
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataInteger
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataSet
>
> > https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataString
>
> >
>
> >
>
> >
>
> > p.s. wow, you are writing XML on a cell phone!  :0
>
> >
>
> >
>
> >
>
> > v/r Don
>
> >
>
> >
>
> >
>
> > From: Andreas Plesch <andreasplesch at gmail.com>
>
> > Sent: Sunday, April 2, 2023 6:35 AM
>
> > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>
> > Cc: Holger Seelig <holger.seelig at yahoo.de>; Michalis Kamburelis
>
> > <michalis.kambi at gmail.com>; 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
>
> >
>
> >
>
> >
>
> > 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
>
>
>
>
>
>
>
> --
>
> 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/20230403/62d45169/attachment-0001.html>