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

[John Carlson]

Last round of testing a day or two ago there were compiler errors in
X3D-edit.   I was running NetBeans 12.4 with old plugins and up-to-date
source.
I also run openjdk15.

On Tue, Jun 1, 2021 at 2:05 PM Don Brutzman <brutzman at nps.edu> wrote:

> [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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210601/dc889cff/attachment.html>