[x3d-public] X3D minutes 18 DEC 2020: X3D4 review, ballot in progress, CSS class/style naming collisions, issue resolution continues
Don Brutzman
brutzman at nps.edu
Fri Dec 18 10:20:59 PST 2020
Attendees: Anita Havele, Vince Marchetti, Nicholas Polys, Dick Puk, Don Brutzman.
X3D Weekly Meeting, 09-1000 Pacific time, Friday 18 DEC 2020.
This week we have a feedback and discussion session regarding X3D4 Working Draft 3 ballot, now in progress.
[0.1] Web3D Teleconference Information
https://www.web3d.org/member/teleconference-information
> Please use the following link for all Web3D Consortium Meetings.
>
> Join URL: https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
Confirmed that no Web3D Consortium member-only information is in these minutes.
Prior minutes:
[0.2] [x3d-public] X3D minutes 11 DEC 2020: X3D4 Annex L, HTML authoring guidelines
https://web3d.org/pipermail/x3d-public_web3d.org/2020-December/014265.html
Problem noted: Web3D Comments form needs to have a selection for 4.0. (Tricky problem, this omission only manifests on certain selection combinations on prior menu selections.) Trouble report submitted.
[0.3] Web3D Standards Comment Form
https://www.web3d.org/content/web3d-standards-comment-form
As usual, preparation notes are included in this agenda. Further inputs always welcome.
---
Topics:
1. Our "big picture" is Really Big
From a capabilities perspective, our X3D working group and community have had a stellar year! PBR/NPR/glTF rendering, advanced audio,
Thanks to everyone for your many insights and contributions, we are together reaching a new plateau of productivity with X3D4.
Please stay safe out there with friends and family over the holiday break. Our shared work continues in 2021.
---
2. Questions of interest - any new ideas, or things we haven't answered?
[2.1] X3D Version 4 Overview
https://www.web3d.org/x3d4
Discussion and review.
a. FontStyle and ScreenFontStyle have style attribute, which is a name collision for CSS style attribute.
Meanwhile Annex L HTML Authoring Guidelines
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html#CSS
How to handle?
Of note is that X3DJSAIL dealt with a similar issue before, a Java-API problem with CSS 'class' colliding with Java reserved word 'class' and renamed it cssClass. Similar approach was likely necessary in Python; such collisions are to be expected for common terms.
X3D4 general goals and priorities:
a. Retain information in legacy X3D/VRML models.
b. Retain as much existing common practice as possible.
c. Minimize field name changes when possible/advisable.
d. Allow consistent portability of content across all X3D file encodings and language bindings (even if something like a CSS-related value is not expected to be used).
e. Permit interoperation with HTML and CSS without conflict.
It would seem we have three approaches possible here:
=====================================================
i. Specialized CSS-field names peculiar to FontStyle and ScreenFontStyle,
ii. Change X3D FontStyle and ScreenFontStyle /style/ fields, renaming as /x3dStyle/ or /presentationStyle/ or somesuch, avoiding future naming collisions altogether. This would obviously be part of our differences between X3D3 and X3D4.
iii. Rename reserved words in X3D to cssClass and cssStyle for consistency throughout all of our file encodings and programming-language bindings. Also avoids collision with HTML DOM CSS 'class' and 'style' attributes within the DOM.
=====================================================
Of related note is that X3DOM already uses WebFonts to control font and style.
[2.2] X3DOM Text Example
https://x3dom.org/x3dom/example/x3dom_text.html
[2.3] Webfonts: W3C Fonts on the Web
https://www.w3.org/Fonts
All insights welcome.
Next steps:
- document in Mantis,
- continue implementation testing, report back. Temporary testing of option (iii) seems possible now, option (ii) is promising.
- Broader discussion is certainly appropriate.
c. Testing continues on X3D XML Schema, DOCTYPE, X3DUOM etc. Updated release expected next week.
---
3. Ballot sent to Web3D members
Public version of X3D4 Architecture (working draft 3) includes all markup for additions/changes/deletions.
[3.1] X3D4 Public Working Draft Specification third release
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/
Private member version is pristine, with editing markup automagically removed from the HTML pages using an XML-based publication stylesheet.
These online documents will remain unchanged during the ballot period.
Specification documents are maintained as part of our member-only github version control. Account permission requests are welcome.
[3.2] Github version control: Web3DConsortium / X3D
https://github.com/Web3DConsortium/X3D
X3D Specification editors (Dick and yours truly) expect to steadily continue with issue resolution. As ever: technical-tradeoff discussions occur on x3d-public list, with summarized technical details collected in Mantis.
[3.3] Web3D Consortium Mantis Issue Tracker
https://www.web3d.org/member-only/mantis/
All specific ballot comments will be recorded and resolved (or marked as deferred) shortly after the 30-day ballot period closes.
Decision point: if approved by Web3D Consortium Board of Directors in January 2020, the X3D4 Architecture Committee Draft (CD) will be submitted to ISO IEC/JTC 1/SC 24 for international review and disposition.
---
4. X3D4 outreach, encouraging membership in support of ballot
Seems like a big opportunity for outreach... Consortium work is in progress on this score.
[4.0] Join the Web3D Consortium
https://www.web3d.org/join
There has been no better time to be a Web3D Consortium Member, much value continues to steadily emerge.
----
5. Deprecating GeoMetadata "data" field.
> We are looking closely at this and do not recognize a need for the GeoMetadata
> /data/ field. Certainly the information is duplicative; if another geospatial
> node uses a given GeoMetadata node, that occurs elsewhere and is definitive.
> Any time there is duplication (such as this /data/ field) that is an opportunity
> for error and inconsistency that we do not want.
Mantis is a great tool that helps us keep track of all this immense amount of information coherently.
Long form of an issue-notification message follows so that anyone can see what are able to track, even over a number of years if necessary.
For GeoMetadata "data" field, please see comments by Don/Dick and Mike below. Shall we deprecate and declare it nonfunctional in X3D4?
On 12/17/2020 8:59 AM, Mantis Bug Tracker wrote:
>
> A NOTE has been added to this issue.
> ======================================================================
> https://www.web3d.org/member-only/mantis/view.php?id=802
> ======================================================================
> Reported By: walroy
> Assigned To: brutzman
> ======================================================================
> Project: X3D
> Issue ID: 802
> Category: 19775-1 (Abstract)
> Tags: V4.0
> Reproducibility: N/A
> Severity: minor
> Priority: normal
> Status: assigned
> ======================================================================
> Date Submitted: 2015-07-04 06:50 PDT
> Last Modified: 2020-12-17 08:59 PST
> ======================================================================
> Summary: 25.3.5 GeoMetadata "data" field: append type
> restriction or consider deprecating
> Description:
> 25.3.5 GeoMetadata
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#GeoMetadata
>
> -----------------
> Description: SFNode field missing node type.
>
> Node signature says
> GeoMetadata : X3DInfoNode {
> MFNode [in,out] data []
>
> Appears to need to apply node type restriction. Default would seem to be
> X3DNode but probably this ought to be restricted to geospatial and
> metadata/WorldInfo nodes.
> -----------------
>
> Additional Information:
> Submitted on Thursday, 2015, June 4 - 8:25pm
> by brutzman (brutzman )
> IP: 205.155.65.226
>
> See: http://www.web3d.org/node/1694/submission/579
>
> ======================================================================
> ----------------------------------------------------------------------
> (0002034) walroy (manager) - 2017-05-01 05:21
> https://www.web3d.org/member-only/mantis/view.php?id=802#c2034
> ----------------------------------------------------------------------
> -- Submitter indicates that this comment may be public: *Yes* --
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 25.3.5 GeoMetadata
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#GeoMetadata
>
> -----------------
> Subject: GeoMetadata MFNode data field needs restriction on allowed node types
>
> GeoMetadata node signature is:
>
> GeoMetadata : X3DInfoNode {
> MFNode [in,out] data []
> SFNode [in,out] metadata NULL [X3DMetadataObject]
> MFString [in,out] summary []
> MFString [in,out] url [] [URI]
> }
>
> This allows the "data" field to include any node whatsoever, which is contrary
> to specification semantics later in this section:
> "The data field is used to list all of the other nodes in a scene by DEF name
> that reference the data described in the GeoMetadata node." etc.
>
> Solution approaches include listing all nodes exhaustively or else perhaps
> creating an X3DGeospatialObject badge interface. Possible correction thus looks
> like
>
> MFNode [in,out] data [] [*List all nodes or create an X3DGeospatialObject interface*]
>
> p.s. Worth noting is that the GeoMetadata approach is different than the other
> Metadata nodes. Possibly it might be refactored and merged for X3D version 4.
> -----------------
>
> Submitted on Sunday, 2017, April 30 - 5:08pm
> by brutzman (brutzman )
> IP: 162.225.68.164
>
> See: http://www.web3d.org/node/1694/submission/1356
>
> ----------------------------------------------------------------------
> (0002035) walroy (manager) - 2017-05-01 05:28
> https://www.web3d.org/member-only/mantis/view.php?id=802#c2035
> ----------------------------------------------------------------------
> In addition, I reviewed the XML schema, DTD, and JSON schema. In all three cases
> I noted that they only permitted geospatial nodes, as well as ProtoInstance. The
> permitted content was done by listing all the allowed nodes.
>
> ---------------------
>
> Submitted on 1st May by Roy Walmsley
> See http://web3d.org/mailman/private/x3d_web3d.org/2017-May/006040.html
>
> ----------------------------------------------------------------------
> (0002685) brutzman (developer) - 2020-12-15 15:01
> https://www.web3d.org/member-only/mantis/view.php?id=802#c2685
> ----------------------------------------------------------------------
here it is
> Spec editor review, posted message:
> =========================
>
> We are looking closely at this and do not recognize a need for the GeoMetadata
> /data/ field. Certainly the information is duplicative; if another geospatial
> node uses a given GeoMetadata node, that occurs elsewhere and is definitive.
> Any time there is duplication (such as this /data/ field) that is an opportunity
> for error and inconsistency that we do not want.
>
> Wondering: can we simply deprecate this field as nonfunctional?
>
> ----------------------------------------------------------------------
> (0002731) mmccann (developer) - 2020-12-17 08:59
> https://www.web3d.org/member-only/mantis/view.php?id=802#c2731
> ----------------------------------------------------------------------
> I'm in favor of making GeoMetadata consistent with other Metadata nodes.
>
> The ambiguity of the data attribute would seem to lead to very confusing
> content. I know of no examples of its use this way, and perhaps it's a good
> thing there are no examples of its use!
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2015-07-04 06:50 walroy New Issue
> 2015-12-19 09:14 brutzman Assigned To => brutzman
> 2015-12-19 09:14 brutzman Status new => confirmed
> 2017-05-01 05:21 walroy Note Added: 0002034
> 2017-05-01 05:26 walroy Note Added: 0002035
> 2017-05-01 05:28 walroy Note Edited: 0002035
> 2020-12-13 11:41 brutzman Tag Attached: V4.0
> 2020-12-13 11:41 brutzman Status confirmed => assigned
> 2020-12-15 09:56 brutzman Note Added: 0002685
> 2020-12-15 15:00 brutzman Summary 25.3.5 GeoMetadata -
> Append type restriction => 25.3.5 GeoMetadata "data" field: append type
> restriction or consider deprecating
> 2020-12-15 15:01 brutzman Note Edited: 0002685
> 2020-12-17 08:59 mmccann Note Added: 0002731
> ======================================================================
And so it goes. Have fun with X3D4! 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