<div dir="auto"><div>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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><Shape bboxDisplay='true'><br>       <MetadataFloat name='extension' containerfield='bboxColor' value=' "0.7 0.8 0.9" '/><br>       <MetadataFloat name='extension' containerfield='bboxMargin' value=' "0.1" ' /><br>     <Sphere/><br></Shape><br><br>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.</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">---on the phone---</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, Apr 2, 2023, 12:27 AM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excellent catch regarding MetadataDouble, thanks Holger.<br>
<br>
Andreas, for full-fledged node definitions, we might also use an extension schema and DTD for native expression.<br>
<br>
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.<br>
<br>
v/r Don<br>
<br>
-----Original Message-----<br>
From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> <br>
Sent: Saturday, April 1, 2023 7:48 PM<br>
To: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a>><br>
Cc: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank" rel="noreferrer">michalis.kambi@gmail.com</a>>; Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" target="_blank" rel="noreferrer">holger.seelig@yahoo.de</a>>; Doug Sanden <<a href="mailto:gpugroup@gmail.com" target="_blank" rel="noreferrer">gpugroup@gmail.com</a>>; x3dom mlist <<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank" rel="noreferrer">x3dom-users@lists.sourceforge.net</a>>; X3D <<a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a>><br>
Subject: Re: [x3dom-users] [x3d-public] bboxDisplay considerations; metadata nodes for new field extensions<br>
<br>
NPS WARNING: *external sender* verify before acting.<br>
<br>
<br>
I misremembered. In fact, all Metadata types hold MF values. But it still seems very verbose to have a Metadata node for each field.<br>
For validation of extension fields a vocabulary would still be needed and have the actual field type like SFColor.<br>
<br>
An extension node value could look like:<br>
<br>
<MetadataSet name="extension-node"><br>
  <MetadataString name="node-name" value=' "BinaryGeometry" ' /><br>
  <MetadataString name="node-fields" value=' "url=\' \"datafile.dat\"<br>
\' "  "primitiveMode=\'LINES\'" ...  ' /> </MetadataSet><br>
<br>
or simply<br>
<MetadataString name="extension-node" value=' "\<BinaryGeometry\>"<br>
"url=\' datafle.dat\' " "primitiveMode=\'LINES\'" ... ' /><br>
<br>
Parsing is harder, but hopefully schematron/xslt/xpath would be sufficiently expressive to allow the <a href="http://verbosity.be" rel="noreferrer noreferrer" target="_blank">verbosity.be</a> at a minimum.<br>
<br>
Some ideas,<br>
<br>
Andreas<br>
<br>
On Sat, Apr 1, 2023 at 5:41 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> Hi Don,<br>
><br>
> Using metadata as an extension mechanism may be feasible. It would <br>
> require more thought on how to represent non-standard nodes in <br>
> metadata in addition to fields. For example, x3dom has the popular <br>
> BinaryGeometry node.<br>
><br>
> The metadata seem quite verbose. It would probably suffice to have a <br>
> single MetaDataMFString with all non-standard attributes:<br>
><br>
> <Shape bboxDisplay='true'><br>
>    <MetadataString name='extension-fields' value=' " bboxColor=\'0.7<br>
> 0.8 0.9\' " "bboxMargin=\'0.1\' " /><br>
>    <Sphere/><br>
> </Shape><br>
><br>
> Instead of the "=" sequential name-value pairs may be preferable. The <br>
> meaning would be "add to the node as attribute name-value pairs in xml <br>
> encoding before initial parsing".<br>
><br>
> This makes parsing a bit harder but since MFtypes can generally only <br>
> be represented as strings in Metadata, such parsing is necessary in <br>
> any case.<br>
> For x3dom, the metadata values would only be used for initialization of fields.<br>
><br>
> Another way to think about validation of non-standard extensions is to <br>
> actually provide custom validation for such documents. This seems hard <br>
> but perhaps could be accomplished with a plug-in system for a base <br>
> validator system. Plug-ins could then be provided by extension <br>
> authors.<br>
><br>
> Finally, it is not unreasonable to keep the current semantics of <br>
> validation. Adding non-standard fields and nodes invalidates a <br>
> document.<br>
><br>
> Best, Andreas<br>
><br>
> On Sat, Apr 1, 2023 at 3:57 PM Brutzman, Donald (Don) (CIV) <br>
> <<a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a>> wrote:<br>
> ><br>
> > Thanks for continuing news about this excellent progress.<br>
> ><br>
> > Am thinking we might all agree to regularize addition of nonstandard fields in a way that still passes content validation.<br>
> ><br>
> > For example, non-standard experimental example<br>
> ><br>
> > <Shape bboxDisplay='true' bboxColor='0.7 0.8 0.9' bboxMargin='0.1' ><br>
> >    <Sphere/><br>
> > </Shape><br>
> ><br>
> > Might be equivalently and validly expressed as<br>
> ><br>
> > <Shape bboxDisplay='true'><br>
> >    <MetadataSet name='extension'><br>
> >         <MetadataString name='bboxColor' value='0.7 0.8 0.9'/><br>
> >         <MetadataString name='bboxMargin' value='0.1' /><br>
> >    </MetadataSet><br>
> >    <Sphere/><br>
> > </Shape><br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > The X in X3D is Extensible... looking forward to continued innovation and practice/progress together.<br>
> ><br>
> > v/r Don<br>
> ><br>
> ><br>
> > -----Original Message-----<br>
> > From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>><br>
> > Sent: Saturday, April 1, 2023 6:43 AM<br>
> > To: X3D <<a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a>><br>
> > Cc: x3dom mlist <<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank" rel="noreferrer">x3dom-users@lists.sourceforge.net</a>><br>
> > Subject: Re: [x3dom-users] [x3d-public] bboxDisplay considerations<br>
> ><br>
> > The bboxDisplay field is now available for bounded objects (grouping nodes and shapes) in the dev. version of x3dom.<br>
> ><br>
> > The color of the displayed bounding box can be customized with the non-standard bboxColor field, and the size expanded with the bboxMargin field.<br>
> ><br>
> > Enjoy ! Andreas<br>
> ><br>
> > On Thu, Mar 30, 2023 at 2:19 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> wrote:<br>
> > ><br>
> > > I think it will be very useful to allow different colors for <br>
> > > different sets of bounding boxes. Here are the rotating cubes with <br>
> > > two sets of bounding boxes. The yellow ones react to a <br>
> > > TouchSensor, the orange ones do not:<br>
> > > [...]<br>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div></div>