[x3d-public] X3D agenda 24 JAN 2020

vmarchetti at kshell.com vmarchetti at kshell.com
Fri Jan 24 06:46:31 PST 2020

A possible addition to today's agenda, or a future meeting

X. Ugliness of the MetadataSet in XML encoding

As we consider more detailed schemes for domain specific metadata in X3D, we are noticing more and more that in the MetadataSet, in XML encoding, every X3DMetadataObject that is an element of that set must have the xml attribute 'containerField' explicitly defined as 'value'. This is necessary to disambiguate the status of each element of the set; without that xml attribute value defined that X3DMetadataObject would be considered metadata on the parent MetadataSet, rather than an element of the set.

I have not found this issue as a Mantis ticket, I found it referred to in these email threads (in some cases, only tangentially related to the subject of the thread)

[med] 4/13/2017 "considering general conversion of metadata..."  http://web3d.org/mailman/private/med_web3d.org/2017-April/000931.html
[cad] 4/14/2017 "Metadata Structure Idea" http://web3d.org/mailman/private/cad_web3d.org/2017-April/000702.html
[med] 9/2/2017  "Advice on Non-3D Metadata in XML"    http://web3d.org/mailman/private/med_web3d.org/2017-September/000958.html
[x3d-public] 7/11/2018 "containerField updates pushed for X3D 4.0 XML Schema" http://web3d.org/pipermail/x3d-public_web3d.org/2018-July/009108.html ; http://web3d.org/pipermail/x3d-public_web3d.org/2018-July/009109.html
[x3d-public] 2/3/2019  "gltf metadata: X3Dv4 MetadataSet design issue" : http://web3d.org/pipermail/x3d-public_web3d.org/2019-February/010020.html

Here is my (VM) biased view of this potential issue for resolution in X3Dv4
-- Those explicit containerField='value' entries in the XML encoding  are ugly and verbose, but that's not a problem; XML is inherently ugly and verbose.
-- It's not a validation issue; throughout the X3D abstract model an X3DMetadataObject is either a value of a field 'metadata' (every node) or a field 'value' in MetadataSet.  This can be validated; beyond that there really is no other way; in X3D v3.3, to distinguish whether a XML child of MetadataSet is to be interpreted as an element of the set or as metadata on the set.
-- Since, I argue, the problem is aesthetic only, there is no justification for breaking backward compatibility. I would consider a proposal that requires conversion of an X3D v3.3 file, separate treatment by browsers based on the value of the X3D version #, or XML processing with rules that go beyond what can be expressed with a DTD;  to break backward compatibility.

I did not see a proposal in the above emails that alleviate this issue and maintain backwards compatibility.
As usual, willing to be shown that I'm wrong.

Vince Marchetti

> On Jan 24, 2020, at 8:15 AM, Don Brutzman <brutzman at nps.edu> wrote:
> 1.* General Topics*
> a. Web3D 2020 Conference updates
>   https://www.web3d.org/event/web3d-2020-conference-seoul-korea
> b. Releases
> - view3dscene converter
>  https://twitter.com/castleengine/status/1215751985523232771
>   https://castle-engine.io/wp/2020/01/10/convert-to-x3d-from-gltf-obj-stl-collada-and-change-x3d-encodings-using-online-castle-game-engine-converter
> - Xj3D NPS branch upgraded to Java 13 and moved to
>  https://gitlab.nps.edu/Savage/xj3d
> c. HelloGermany.x3d
>   https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes
>   https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloGermany.x3d
>   https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloGermanyIndex.html
>   https://www.w3.org/International
> d. HelloWorldMinimal.x3d posted to WikiBooks
>   https://en.wikibooks.org/w/index.php?title=Computer_Programming/Hello_world
>   https://en.wikibooks.org/w/index.php?title=Computer_Programming/Hello_world#X3D_(Extensible_3D)
>   https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldMinimal.x3d
>   https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldMinimalIndex.html
>   e. Other news
> ----
> 2. *Validation:* much work on tools, all succeeding to match technical dialog to date.  Summary noted here, continues to track group decisions on X3Dv4.  Discussion welcome if any of these many details are unclear.
> https://www.web3d.org/specifications
> https://www.web3d.org/specifications/x3d-schema-changelog.txt
> 18 JAN 2020, brutzman
> - Relaxation of some name constraints from NMTOKEN to SFString for meta, Metadata nodes,
>  CAD nodes. Did not change xs:NMTOKEN to xs:token, keeping exact match with DOCTYPE.
>  No change needed in DOCTYPE, already matched these conventions.
> - fix content model for GeoOrigin (which is X3DNode, not X3DChildNode) as initial
>  element after metadata field.  Improved regularity enabled X3D-Tidy fix for
>  ordering of child nodes.
> - (v4.0) add visible field to X3DBoundedObject, Mantis 1271
>  https://www.web3d.org/member-only/mantis/view.php?id=1271 (no longer named 'hidden')
> - (v3.2+) CollisionCollection implements X3DChildNode, not X3DNode
> - (v4.0) CollisionCollection contains nodes with X3DBoundedObject interfaces, so
>  TODO CollisionCollection needs to be marked in specification as X3DBoundedObject as well.
> - TODO (v4.0) PointSet, LineSet, IndexedLineSet implement X3DComposedGeometryNode
>  similar to other geometry nodes, allowing Normal and texture coordinate children
> - TODO Consider StaticGroup implement X3DGroupingNode
> Discussion on the TODO items above will be helpful for continuing progress.
> ----
> 3. *Mantis issues:* ongoing progress reported on mail list.  Specific issues for today:
> a. Dick and Don have begun the "minor" comments which are mostly HTML clarifications/cleanups in the specification.  We continue to meet 1-2 times weekly to address the backlog of pending comments.
>   [x3d-public] X3Dv4 mantis issue resolutions
>   http://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011702.html
> Updated X3Dv4 specification available at
> https://github.com/Web3DConsortium/X3D/tree/master/ISO-IEC19775/ISO-IEC19775-1/ISO-IEC19775-1v4.0/ISO-IEC19775-1v4-WD1
> Of note: issues that are fixed and committed to specification HTML source on github are marked "resolved" pending final group review of all completed issues together.  Meanwhile further review is welcome and comments will be addressed.
> Mantis workflow process flowcharts and description of terminology definitions (prepared thanks to Roy Walmsley) are found at
> * https://www.web3d.org/member/mantis-workflow
> * https://www.web3d.org/member/mantis-definitions
> * https://www.web3d.org/member-only/mantis/view_all_bug_page.php
> ----
> b. During terminology review for a related ISO specification, we noticed that the term 'model' is not included in our X3D Architecture glossary.
> Several definitions are included in Mantis issue 1278, further suggestions welcome.
> * https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/glossary.html
> * https://www.web3d.org/member-only/mantis/view.php?id=1278
> ----
> c. Mantis 1277: Provide field on X3DBoundedObject nodes to display bounding boxes.
>   https://www.web3d.org/member-only/mantis/view.php?id=1277
> Further discussion on Thursday's Design Printing Scanning (DPS) Working Group call summarized and added to issue, repeated publicly on the mailing list thread.
> * [x3d-public] candidate feature: display bounding box
>  http://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011705.html
> Since there are multiple implementations already in existence that handle bounding box display efficiently, it would be helpful to focus any discussion on usability issues.
> - bounding boxes can assist in navigation, selection, and displaying state
> - facilitating author use of bounding boxes for users in X3D is helpful
> - since bounding box display is complementary to bounded object visibility, now is appropriate time to consider it.
> Suggested prose to bash on follows.  (Incidentally it does not mandate how a browser might efficiently execute this task.)
> "When showBBox is true, a wireframe bounding box is displayed for the associated geometry."
> ----
> Have fun with X3D!  8)
> all the best, Don
> -- 
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the x3d-public mailing list