[x3d-public] [x3dom-users] bboxDisplay considerations; metadata nodes for new field extensions
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Apr 2 09:14:12 PDT 2023
Interesting containerField-example approach, but…
a. 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.
b. 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.
c. 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.
d. 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.proof/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#Shape
* 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 <mailto: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 <mailto:andreasplesch at gmail.com> >
Sent: Saturday, April 1, 2023 7:48 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> >
Cc: Michalis Kamburelis <michalis.kambi at gmail.com <mailto:michalis.kambi at gmail.com> >; Holger Seelig <holger.seelig at yahoo.de <mailto:holger.seelig at yahoo.de> >; Doug Sanden <gpugroup at gmail.com <mailto:gpugroup at gmail.com> >; x3dom mlist <x3dom-users at lists.sourceforge.net <mailto:x3dom-users at lists.sourceforge.net> >; X3D <x3d-public at web3d.org <mailto: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 <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fverbosity.be%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C51f09fae64e6420bf3c208db337f2415%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638160393398707955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C9yWMzWwna5HOeb%2BHq4MGU7BkWz%2BnuiIUiE6PALib5k%3D&reserved=0> at a minimum.
Some ideas,
Andreas
On Sat, Apr 1, 2023 at 5:41 PM Andreas Plesch <andreasplesch at gmail.com <mailto: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 <mailto: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 <mailto:andreasplesch at gmail.com> >
> > Sent: Saturday, April 1, 2023 6:43 AM
> > To: X3D <x3d-public at web3d.org <mailto:x3d-public at web3d.org> >
> > Cc: x3dom mlist <x3dom-users at lists.sourceforge.net <mailto: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 <mailto: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/14d8f60b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230402/14d8f60b/attachment-0001.p7s>
More information about the x3d-public
mailing list