[x3d-public] X3D minutes 31 JAN 2020: X3Dv4 issues, XML Metadata containerField, consolidating mismatched field names
Don Brutzman
brutzman at nps.edu
Fri Jan 31 10:19:10 PST 2020
1. Usual coordinates for telcon today, appearing below.
Attendees: Anita Havele, Vince Marchetti, Dick Puk, Don Brutzman.
Participant review confirmed that no member-only information is included in these minutes.
Last meeting:
* [x3d-public] X3D minutes 24 JAN 2020: X3Dv4 Interchange-profile Text, visible, displayBBox, XML Metadata* default containerField
http://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011710.html
===========================================
2. *News and Events*
a. Web3D 2020 Conference, Seoul Korea, 24-26 June 2020
http://2020.web3dconference.org
This is an important annual milestone for reporting and discussing progress. Also our 25th anniversary of progress - wow.
Keep writing! Submissions deadline 22 February 2020.
-----
b. Recent release of view3dscene converter is being kept up to date to match glTF mappings to X3Dv4. Work in progress, expect to see more in February.
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
Our plan, upon reviewing forthcoming specification changes for Physically Based Rendering (PBR) and corresponding lighting model, is to convert all of the publicly available glTF reference examples to X3D. That should certainly clarify everyone's understanding, implementations and other models for X3D and glTF.
-----
c. Xj3D NPS branch upgraded to Java 13 and moved from Sourceforge subversion to NPS gitlab server. Runs on multiple operating systems (Windows, MacOSX, Linux to be confirmed shortly). Continuing re-integration into other tools, updating Distributed Interactive Simulation (DIS) support.
https://gitlab.nps.edu/Savage/xj3d
https://savage.nps.edu/Savage/developers.html#Xj3D
-----
d. SISO Simulation Interoperability Workshop (SIW) Orlando FL, 10-13 FEB. Includes multiple sessions relating to DIS.
https://www.sisostds.org/2020SIW.aspx
Interestingly our revised OpenDIS7 library and Wireshark both implement all 72 DIS PDUs. NPS developers are currently designing a series of unit-test patterns to confirm interoperability of data streams.
===========================================
3. *Schedule planning.* In addition to Mantis issues and specification updates, additional topics are possible for following meeting dates.
a. 7 FEB
b. 14 FEB
c. 21 FEB: PBR review with Michalis, if possible.
d. 28 FEB
e. 6 MAR: Sound and Audio with Thanos and Efi, if possible.
Suggested topics:
- example X3D models party
- implementers discussion
- updating Node Inventory Comparison
===========================================
4. *Mantis issues*
a. /Shrinking issue set/. Dick and I continue applying editorial changes into the draft specification on github. All issues for X3Dv4 are so marked, as RESOLVED. We close issues only after final member review prior to submission.
Some older issues marked RESOLVED needed some additional work, but we were unable to edit them due to an apparent permissions problem. Webmaster informed. In these cases we just started a new issue, cross-linked with the old issue, describing what additional steps are taken. Example:
* Mantis 568: 35.4.2 LayerSet - Change Field Bounds
https://www.web3d.org/member-only/mantis/view.php?id=568
* Mantis 1279: further work on mantis 568
https://www.web3d.org/member-only/mantis/view.php?id=1279
-----
b. Text/FontStyle as part of Interchange Profile? From last week. Seems useful, no negatives known, final review and resolution today please.
> 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
>
> Of note is that Text node requires Immersive profile, or (less commonly) Interchange profile with Text component level 1. Wondering, should we relax this requirement and add it to Interchange profile instead? Of note is that X_ITE and X3DOM do not forbid its use under Interchange profile. Historically there was concern about computational complexity for tessellation of fonts - that concern no longer exists (thank you Moore's Law). Related: we should ensure FontStyle matches.
Context: Immersive Profile is heavyweight, and COMPONENT statements are not commonly part of entry-level X3D understanding.
HelloWorld in several hundred other languages is always posed a minimal exemplar of language syntax/capability.
> Plain old Web authors won't want to worry about this.
>
> Xj3D might be the only browser that enforces draconian display - we can fix that to match the correct answer.
... and parenthetically we will be working on Xj3D console diagnostics, going from good to better, so hopefully we can make it a more robust testing platform.
Incidentally Xj3D is used for all off-screen rendering of Viewpoint images found in X3D Examples.
* Examples: Scene Archives for X3D
https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
> There are similar issues with CSS that are worth looking at downstream. For now they are "orthogonal" in that
> (a) they change the scene graph via DOM, and so are always matching,
> (b) they offer WebFonts to DOM-based JavaScript players like X3DOM and X_ITE.
>
> Path forward: add it as a Mantis issue, give it a week on the mailing list, and look at FontStyle implications next week. Once/if no objections then we can approve this useful relaxation.
- No comments received.
- Text and FontStyle are intimately interrelated, couldn't do one without other.
- Equally so for internationalized text.
Consensus: relax Text/FontStyle baseline support to Interchange Profile.
-----
c. Mantis issue 1276: name types: whitespace constraints, NMTOKEN and SFString
https://www.web3d.org/member-only/mantis/view.php?id=1276
Recommended next step: update prose in specification to describe naming constraints.
Note that no whitespace in HAnim node names allows us to support medical taxonomies, animation tools and even Inverse Kinematics (IK) without fear of confounding node references. Meanwhile, any contained Metadata within such humanoids (sports playback, cartoons, medical records, etc.) can contain whitespace.
Consensus: proceed. Dick and Don take for action.
-----
d. 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
Searching the X3D Architecture specification for 'model' reveals 206 occurrences.
Inspection of many of these occurrences reveals that the term 'model' is typically used with another adjective, i.e. event model, lighting model, 3D model, object model, world model, etc. etc.
Dick reports that original VRML specification did not include 'model' because the dictionary definition was satisfactory already. That is ISO editorial policy, with OED being authoritative.
Thus we are OK and no need to add this definition.
Consensus: close without action. So done.
-----
e. /Displaying bounding box/ as animatable user-experience assist, on a par with /visible/ field if browsers are given latitude when implementing X3DBoundedObject.
Accept, reject or defer? Great discussion today.
> 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 end users in X3D is helpful
> - /displayBBox/ is distinct from /visible/ field.
> - since bounding box display is complementary to bounded object visibility, now is an appropriate time to consider it.
>
> Suggested prose to bash on follows, improved during call. (Incidentally it does not mandate how a browser might efficiently execute this task.)
>
> "When displayBBox is true, the bounding box is displayed for the associated geometry."
>
> We agreed to let consideration of this issue continue on the mailing list.
We again discussed tradeoff arguments presented and recorded earlier in 'visible' mechanism.
- simplicity of authors implementing /visible/ feature: is otherwise quite onerous and not repeatable; it is simple when using DOM.
- not simple for authors to add bounding boxes, but browsers do implement bounding boxes consistently so this is easy for them.
Important to note that this functionality is distinct from the 'visible' field.
=================================
Suggested specification addition:
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/group.html#X3DBoundedObject
10.3.1 X3DBoundedObject
SFBool [in out] displayBBox FALSE
"When /displayBBox/ is true, the bounding box is displayed for the associated geometry.
The bounding box is displayed regardless of whether contained content is /visible/."
Note that the intent is to allow a browser to display a bounding box in whatever manner they see fit.
(Editorial sidebar: using the word 'display' for interface functionality and 'render' for geometry seems like good phrasing.)
=================================
Not everyone 100% convinced that these are necessary, but everyone can live with it.
Consensus:
- proceed with including both 'visible' and 'displayBBox' fields.
- Later consider/confirm that implementation/evaluation is satisfactory prior to final approval of X3Dv4 specification.
-----
f. /XML encoding for Metadata* nodes containerField/
> d. Regarding XML encoding of Metadata nodes, and issues raised in Vince's email today:
>
> * [x3d-public] X3D agenda 24 JAN 2020 (i.e. MetadataSet in XML encoding)
> http://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011708.html
>
> TODO: Don will create an issue to capture and propose simple solution: change default containerField in XML schema to 'value' so that verboseness is reduced. On deck for mailing list post and discussion next week.
Vince also writes helpfully this morning:
> The default value for containerField for the Metadata nodes is defined in the x3d v3.3 DTD as 'metadata' (https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/x3d-3.3.dtd)
> -- see ATTLIST element for the individual ELEMENT nodes for MetadataDouble,MetadataFloat, etc.
>
> There is no DTD corresponding to X3D v4 in the github repository, however I do not think the default values recommended in the authoring hints can be expressed in a DTD.
DTD is maintained at
* https://www.web3d.org/specifications
https://www.web3d.org/specifications/x3d-4.0.dtd
https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html
We will add X3D XML Schema and DOCTYPE as informative annexes to the 19776-1 XML Encoding specification when that is next updated.
> ------
>
> The change in the default value for containerField will potentially change the meaning of X3D v3.3 metadata which makes use of the default values to reduce XML verbosity. In this example:
>
> <MetadataSet name="Milestones">
> <MetadataString name="approval" value='"2020-01-19"'/>
> <MetadataString containerField="value" name="design" value='"2020-03-12"'/>
> <MetadataString containerField="value" name="implementation" value='"2020-04-12"'/>
> </MetadataSet>
>
> Under X3D v3.3 the approval entry means metadata on the set; perhaps indicating when the set of milestones for a project was approved.
>
> Under X3D v4 , with this same XML, the approval entry would be treated as another element of the set.
Going from v3.3 example above to v4.0 would result in tersest form:
<MetadataSet name="Milestones">
<MetadataString containerField="metadata" name="approval" value='"2020-01-19"'/>
<MetadataString name="design" value='"2020-03-12"'/>
<MetadataString name="implementation" value='"2020-04-12"'/>
</MetadataSet>
Specifically this would be a change in X3Dv4 XML encoding, with some forward/backward compatibility issues for converting and for parsing X3Dv4 versus X3Dv4.4. (Parsing issues are perhaps avoided however since the great major of XML parsers use DTD or Schema defaults.)
Dick mentioned a MetadataRecord node possibility, but this seems even less terse and less compatible. Similar to MetadataDate; both of these additions would change our X3D Architecture nodes and enlarge implementation requirements.
Noteworthy:
- all Metadata nodes also include a /reference/ field, which we have no quibbles with.
- MetadataSet /value/ is MFNode, and other Metadata nodes have differently typed /value/ fields.
> One consequence of this change is that in the interim time, between the time the v4 spec is finalized and the time that implementations and users have switched over to v4, we will need to recommend to authors that the containerField XML attribute be explicitly specified for all children of the MetadataSet node; to prevent breaking the file in the crossover to v4.
Good insight and discussion. Thus an even-more verbose but legal method is to always include containerField in Metadata examples.
<MetadataSet name="Milestones">
<MetadataString containerField="metadata" name="approval" value='"2020-01-19"'/>
<MetadataString containerField="value" name="design" value='"2020-03-12"'/>
<MetadataString containerField="value" name="implementation" value='"2020-04-12"'/>
</MetadataSet>
This portable form is what Vince recommends to authors if we approve this change. (Interestingly all three of the above example are legal, for 3.3/4.0/both versions respectively).
* X3D Scene Authoring Hints: Metadata Nodes
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Metadata
"Typically the Metadata nodes have default containerField='metadata' except when they are child values of a MetadataSet node, in which case they have containerField='value'".
Recommended improvement summary:
- No change in X3D Architecture.
- X3Dv4 XML encoding: change default containerField to 'value' since this is by far the most common occurrence?
- Some impact on prior content that already had containerField='value' (the common case), maybe go verbose.
- XMLv4 examples become terser and more readable (though maybe not if conversion is to be avoided for v3 and v4).
- XMLv4 examples are not directly copyable in terse form as X3Dv3 unless conversion is performed.
- Followup: needs inclusion as a warning in X3D Tooltips, Schematron, X3D-Tidy when converting from X3Dv3 -> X3Dv4.
Close to consensus, i.e. either accept or reject is feasible and can be lived with. Hoping Nicholas and others can review and report.
Related, resolvable in turn:
* Mantis 686: metadata field cannot accept X3DMetadataObject type
https://www.web3d.org/member-only/mantis/view.php?id=686
* Mantis 1092: 7 Core component - MetadataSet or Metadata* node(s) as root nodes
https://www.web3d.org/member-only/mantis/view.php?id=1092
* Mantis 717: 7.3.4 X3DMetadataObject - Add value field
https://www.web3d.org/member-only/mantis/view.php?id=717
* Mantis 1218: 7.2.4 MetadataDate - New node type, or new data type
https://www.web3d.org/member-only/mantis/view.php?id=1218
summary: XML Schema provides most commonly used datatypes for dates, could simply make that the /reference/ in relevant nodes.
-----
g. In a similar light, multiple field renaming and containerField recommendations to review.
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
Three assets appear there:
-1- Use cases:
Variations from containerField defaults
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
-2- Lists of allowed names:
Validation choices for containerField
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
-3- Candidate inconsistencies that could be cleaned up:
Potential future changes for improved consistency of field names
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
Common characteristic of many issues: small inconsistencies in X3Dv4 object model that could be easily resolved if we consolidate field names in a consistent fashion. This does no damage to the functionality of the scene graph or past/future content, but it will require converters and implementations to pay attention to the refinement.
Deprecation might seem to soften any transition, but actually greatly complicates implementations. So for X3Dv4 we should either change field names completely (with no deprecated field names) or not change them at all.
Note that not changing any field names remains feasible, but nevertheless retains the cost present for implementers in handling all of the edge cases that have emerged.
I believe all the information is available for us to consider multiple tradeoffs and resolve the core issue:
- are we optimizing the X3Dv4 scene graph for consistency, or
- are we maintaining X3Dv4 inconsistencies and idiosyncrasies indefinitely.
-----
We went a little longer than usual (thanks guys) but got a lot done today.
===========================================
5. *TODO*
a. Progressive Texture Mapping (PTM) examples located, published.
b. Updated node-support spreadsheet including latest status from FreeWrl (thanks Doug).
Would anyone like to be the maintainer of this asset?
* X3D Node Inventory Comparison
https://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx
https://www.web3d.org/specifications/X3dNodeInventoryComparison.pdf
c. Table of supporting software on X3Dv4 Implementations page.
full: X3D XML Schema, DOCTYPE, Schematron, Tooltips, X3D0-Tidy,
X3D Examples validation, X3DUOM, X3D Java, X3D Python, X3D Ontology
partial: X3DOM, X_ITE, view3dscene, FreeWrl (see Node Inventory Comparison table)
maybe: X3DJSONLD JavaScript
coming: Xj3D, X3D Validator, X3D-Edit
==================================
==================================
==================================
*X3Dv4 Background Information*
Major pieces of work in progress and highly mature include:
a. glTF lighting and physically based rendering, Michalis Kamburelis
b. X3D Sound Component and HTML Audio, Athanasios Malamos and Efi Lakka
c. Projective Texture Mapping (PTM), Kwan Hee Yoo
d. Many specification improvements and additions.
Key references:
[1] X3D Version 4 Overview
https://www.web3d.org/x3dv4
[2] X3Dv4 Highlights
httpss://www.web3d.org/x3dv4-highlights
[3] X3Dv4 Implementations Status
https://www.web3d.org/x3dv4-implementations
[4] Draft X3Dv4 specification from SIGGRAPH, August 2019
https://www.web3d.org/news-story/x3dv4-draft-specification-available-public-now
[5] X3D Specifications: Schema and DOCTYPE Validation
https://www.web3d.org/specifications
[6] Mantis Issue Tracker (requires multiple sets of member login)
https://www.web3d.org/member-only/mantis/view_all_bug_page.php
Web3D Consortium members can quickly see all X3Dv4 issues (with tag V4.0) by selecting the filter "X3Dv4" within mantis.
As specified in the reference pages, our next steps of implement/evaluate over the next quarter include
- finished specification prose in github,
- addressing all mantis issues,
- proper example X3D models available for each node/field,
- validation tools confirming examples are satisfactory,
- two or more implementations (X3DOM and X_ITE, others),
- consensus by working group, approval by Web3D Consortium, submission to ISO.
Here are refined milestones from X3Dv4 Implementations Status page:
_Milestones Timeline_
* /26-31 July 2019/. Publish draft specification plus examples and implementation updates at Web3D2019/SIGGRAPH 2019 conferences.
* /16 December 2019/. Working group accepts X3Dv4 new-technology submissions, with rich capability set publicized for implementation work.
* /31 January 2020/. Specification Editors provide ISO Working Draft on github for use and confirmation by Web3D Consortium members.
* /First quarter 2020/. Implement new components in X3D players, evaluate scene examples for conformance. Publish weekly progress updates.
* /When completed/. Completed ISO Working Draft submitted to X3D Community, Web3D Consortium members, Web3D Board of Directors.
* /BoD approval/. Working Draft upgraded to Committee Draft and submitted with NWIP to ISO.
* /Sequential updates/. Specification updates for 19775-2 Scene Access Interface (SAI), file encodings (XML, ClassicVRML, JSON etc.) and language bindings (JavaScript, Java, Python), and X3D Semantic Web (possibly 19775-3).
==================================
*Teleconference Information*
We are using the Web3D Consortium Zoom channel, to good effect. It allows use of internet audio, screen sharing and chat with links.
We meet regularly on Fridays 0800-0930 pacific. To join the teleconference:
Join URL https://zoom.us/j/148206572 for X3D Working Group
One tap mobile
* US (New York) +19292056099,,148206572 #
* US (San Jose) +16699006833,,148206572 #
Dial by your location, using (nine-digit number from Join URL above)
* US (New York) +1 929 205 6099
* US (San Jose) +1 669 900 6833
Additional information
Web3D Teleconference
http://www.web3d.org/member/teleconference-information
==================================
==================================
==================================
Steady progress throughout. Thanks for all efforts. 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
More information about the x3d-public
mailing list