[x3d-public] X3D minutes 28 May 2021: Activity, implementation updates, CORS, MultiTextureTeapot, SFString parsing, id/class/style fields

Tue Jun 1 12:03:53 PDT 2021

[apologies for late send]

X3D Working Group weekly minutes

Attendees: Anita Havele, Vince Marchetti, Nicholas Polys, Dick Puk, Don Brutzman

No member-only information is included in these minutes.

---

1. Activity and outreach

a. Updated Web3D 2021 Website soon to be activated.

b. Blender meeting:  Tuesday 1 June... cancelled, bad timing.

c. Khronos glTF Environment Based Lighting with Don McCurdy and Michalis Kamburelis: Tuesday 08 pacific or Friday 09 pacific?

d. HAnim meetings to resume, William Glascoe and Myeong Won Lee, to-be-confirmed second/fourth Wednesdays of each month

---

2. Implementation progress.

a. Jordi Cardona colorization Notepad++ progressing, he is looking at their new process.  Am wondering if we should plan for a common color palette across multiple tools.

b. X3D-Edit 4.0 beta testing progress... on brink of new release but now sorting out a problem, stay tuned...

c. X3D Validator currently broken but we found problem in OpenJdk16.0.1, backtracking to 16, sorry for inconvenience.  Full functionality available in X3D-Edit.

d. Trouble reports from John Carlson are helpful, but am only slowly able to keep up...  Keep charging please John!

e. Soon renewing effort with Joe on HAnim, there are perhaps 20 joints without defaults (out of very many) so we will finalize them.

f. Preparing announcement of recent CAD briefings with TC184 SC4 Plenary... still need releasable slidesets/video.

g. Added documentation for CORS, verification/improvements welcome:

===================================================================
[2] X3D Scene Authoring Hints: Cross-Origin Resource Sharing (CORS)
     https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#CORS

     "Cross-Origin Resource Sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served." Wikipedia

CORS is important when locally launching an HTML page displaying X3D models when using X_ITE or X3DOM. These are JavaScript players typically served from their originating websites, and so your local web browser may fail to load them (as well as your X3D model) due to CORS restrictions. This security restriction is well-intentioned but can make testing difficult for authors.

The easiest way to handle CORS requirements is to have a local HTTPS server running privately pn your system. For example, if installed, you might run the following Python 3 invocation in the directory of interest. Once running: open your web browser, and select the page of interest. For example:

$ [system] cd 'C:\x3d-code\www.web3d.org\x3d\content\examples'
   [system] /cygdrive/c/x3d-code/www.web3d.org/x3d/content/examples

$ [system] python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

# Next open web browser to http://localhost:8080
# Next open model of interest, for example HelloWorldX_ITE.html or HelloWorldX3dom.xhtml

References
* Wikipedia: Cross-origin_resource_sharing
* Fetch Standard by WHATWG defines requests, responses, and the fetching process that binds them. See 3.2. CORS protocol.
* Mozilla documentation: Cross-Origin Resource Sharing (CORS)
* X_ITE Issue 72, Supporting CORS in X3D-Edit via Java to support X_ITE presentation of X3D models
* X_ITE Guidance, Using Firefox, Chrome and Opera with Local Files
* X3DOM documentation: Running X3DOM Applications with a Simple Python Server
* Additional TODO: add built-in CORS capabilities to X3D-Edit, X3DJSAIL Java, X3DPSAIL x3d.py python.
===================================================================

---

3. MultiTextureTeapot example

https://x3dgraphics.com/examples/X3dForAdvancedModeling/TextureMapping/MultiTextureTeapotIndex.html

We are exploring multitexture and finding that things look great!  Also found some small differences in two of the players, will continue review on mailing list.

[2] [x3d-public] MultiTextureTeapot example using X3D3.3
     https://web3d.org/pipermail/x3d-public_web3d.org/2021-May/015213.html

---

4. SFString parsing

Working towards resolution on details of long-running issue that has led to irregular parsing of XML for X3D.

Essence: first let XML parsers do their thing, then apply ClassicVRML parsing to the result.

[4.0] ClassicVRML Annex A Grammar
       https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html

Summary of specification refinements: clearly state that

a. Explicitly note in XML encoding that XML parsing rules produce a string value that is next subject to ClassicVRML parsing rules.
b. Explicitly note in ClassicVRML encoding that a solitary \ character is erroneous.
c. Explicitly note in XML encoding that an unquoted MFString value is handled as a singleton SFString element in the MFString list.

This strictly defined refinement will likely lead to some changes in existing parsers.

Cost-benefit tradeoffs exist for each codebase when looking at these rule refinements.  Cost of changing code (for example addition of VRML parsing rules to an XML parser) has potential benefit of consistent solutions for authors and tools, across the entire VRML/X3D ecosystem.

Postel's Rule for robustness: "be strict in what you produce and forgiving in what you accept."  So if existing parsers choose to allow edge-case content that is still their choice.

========================================================
[4.1] Wikipedia: Robustness principle
       https://en.wikipedia.org/wiki/Robustness_principle

In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
========================================================

Warning tools (such as X3D Schematron and X3D Tidy) can provide warnings, and note possible changes, that will help authors (and other tools) avoid edge cases.

Final call for comment please.  We don't want to enact any specification changes if better solutions are possible.

---

5. Adding /id/ field (similarly to HTML /class/ and /style/ fields) as reserved field names - testing in progress.  Gist: an X3D model can include these and is able to convert from one form to another without losing information in those fields.  The information in those fields are subject to Annex L, HTML guidelines, and only active in that context.

Need to confirm in Mantis that the change is intended for X3D Architecture, and not just XML encoding... TODO discuss, then verify or deny... not finding any requirement other than Annex L HTML Guidelines, for now.

============================
L.3.3 Cascading Style Sheets (CSS) considerations
[...]
The reserved /class/ attribute on each X3D node can provide a space-separated list of classes that pertain from associated stylesheets.

The reserved /style/ attribute on each X3D node permits direct definition of style information, rather than referring to styles defined in a separate document [W3C-CSS-Style][W3C-CSS-Snapshot].
============================

Potential addition:  "The reserved /id/ attribute on each X3D node can provide an alternative label used by HTML or other external languages."

Of note is that Annex L is non-normative.  So if we want this to ripple out through all file encodings and programming-language bindings, then normative mention is also needed.

If permissive inclusion of these fields is intended for the entire architecture, then the above three statements need to move outward to main specification, likely in Annex 4 Concepts.  It is considered insufficient to merely state that they are reserved attributes, because Annex L is non-normative.  If the three statements are moved to Concepts, then Annex L can reference them as needed.

There is no intent to require any functional support for these fields other than making them available/persistent.  The editors will continue to consider how to best express this.

Further testing of feasibility continues, update reports maybe next week.

---

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