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

[John Carlson]

Also, some browsers have historically been fussy about http protocol.
X3DJSONLD app.js shows example of running local https server, but you must
provide server encryption files.

On Tue, Jun 1, 2021 at 6:58 PM John Carlson <yottzumm at gmail.com> wrote:

> Okay, found 2 bugs.  In CORS section, there should be “ on “ instead of “
> pn “.   Also, the port numbers between Python server and url should be the
> same.
>
> 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/64c9970a/attachment-0001.html>