<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1082798881;
mso-list-type:hybrid;
mso-list-template-ids:1927081562 67698713 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1857303766;
mso-list-type:hybrid;
mso-list-template-ids:570559132 1469636882 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:16;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1988438632;
mso-list-type:hybrid;
mso-list-template-ids:-965946920 -185429736 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Interesting containerField-example approach, but…<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><ol style='margin-top:0in' start=1 type=a><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>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.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>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.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>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.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>p.s. No additional interior quote marks or brackets when using MetadataDouble, MetadataFloat etc.<o:p></o:p></li></ol><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>Postel’s law – Robustness principle<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>"be conservative in what you do, be liberal in what you accept from others"<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>https://en.wikipedia.org/wiki/Robustness_principle<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>X3D Metadata references:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>X3D for Web Authors (X3D4WA), online chapter 15, Metadata Information<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter15-Metadata/Chapter15-MetadataInformation.html<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>X3D4 Architecture, Core Component<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.review/Part01/components/core.html<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/core.html<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>Shape node, XML validation, Schema and DOCTYPE<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_Shape.html#Link1D7<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#Shape<o:p></o:p></li></ul><p class=MsoListParagraph><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>X3D Tooltips, Metadata* nodes<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataBoolean<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataDouble<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataFloat<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataInteger<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataSet<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>https://www.web3d.org/x3d/content/X3dTooltips.html#MetadataString<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>p.s. wow, you are writing XML on a cell phone! :0<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>v/r Don<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Andreas Plesch <andreasplesch@gmail.com> <br><b>Sent:</b> Sunday, April 2, 2023 6:35 AM<br><b>To:</b> Brutzman, Donald (Don) (CIV) <brutzman@nps.edu><br><b>Cc:</b> Holger Seelig <holger.seelig@yahoo.de>; Michalis Kamburelis <michalis.kambi@gmail.com>; Doug Sanden <gpugroup@gmail.com>; x3dom mlist <x3dom-users@lists.sourceforge.net>; X3D <x3d-public@web3d.org><br><b>Subject:</b> Re: [x3dom-users] [x3d-public] bboxDisplay considerations; metadata nodes for new field extensions<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Andreas<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>---on the phone---<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Sun, Apr 2, 2023, 12:27 AM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>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">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">brutzman@nps.edu</a>><br>Cc: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>>; Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a>>; Doug Sanden <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>>; x3dom mlist <<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank">x3dom-users@lists.sourceforge.net</a>>; X3D <<a href="mailto:x3d-public@web3d.org" target="_blank">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="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" 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">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">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">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">x3d-public@web3d.org</a>><br>> > Cc: x3dom mlist <<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank">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">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<o:p></o:p></p></blockquote></div></div></div></div></div></body></html>