[x3d-public] X3D Working Group agenda 31 JAN 2020: X3Dv4 issues, XML Metadata containerField, consolidating mismatched field names

Don Brutzman brutzman at nps.edu
Fri Jan 31 06:31:25 PST 2020

1. Usual coordinates for telcon today.

* [x3d-public] X3D minutes 24 JAN 2020: X3Dv4 Interchange-profile Text, visible, displayBBox, XML Metadata* default containerField


2. *News and Events*

a. Web3D 2020 Conference, Seoul Korea, 24-26 June 2020

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.


c. Xj3D NPS branch upgraded to Java 13 and moved from SourceForge subversion to NPS gitlab server.  Continuing re-integration into other tools, updating Distributed Interactive Simulation (DIS) support.


d. SISO Simulation Interoperability Workshop (SIW) Orlando FL, 10-13 FEB.  Includes multiple sessions relating to DIS.



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
d. 28 FEB


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

* Mantis 1279: further work on mantis 568


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.
> 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.
> 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.


c. Mantis issue 1276: name types: whitespace constraints, NMTOKEN and SFString

Recommended next step: update prose in specification to describe naming constraints.

Last call to confirm concurrence, then 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

Last call for inputs, then Dick and Don take for action.


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?

> 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.


f. /XML encoding for Metadata* node 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.

X3D Scene AUthoring Hints: Metadata Nodes

"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:
- change default containerField to 'value' since this is by far the most common occurrence.
- XML examples become far terser and more readable.
- No change in X3D Architecture.
- No impact on prior content that already had  containerField='value' (the common case)
- Easily noted as a warning in X3D Tooltips, Schematron, Tidy when converting from X3Dv3 -> X3Dv4.

Discussion please, suggest implementation get tested and any troubles reported back.


g. In a similar light, multiple containerField recommendations to review.

Common characteristic of many issues: small inconsistences in X3Dv4 object model that could be easily resolved if we consolidate field names in a consistent fashion.  This does no damage to the scene graph or past/future content, but it will require converters and implementations to pay attention.  Deprecation can soften the transition.


other priorities?


5. *TODO*

a. Progressive Texture Mapping (PTM) examples located, published.
b. Table of supporting software on X3Dv4 Implementations page.
c. Updated node-support spreadsheet including latest status from FreeWrl (thanks Doug).
d. etc.


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