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

Wed Jun 2 03:55:39 PDT 2021

As for Khronos meeting time (you wrote "Tuesday 08 pacific or Friday
09 pacific"): if you mean next week, then both Tuesday and Friday are
right now fine for me. Please add a calendar invite once the date and
time are confirmed :)

As for SFString / MFString changes in the spec: I admit I read the
meeting notes worried. My strong opinion here is that we *should not*
change the way current X3D classic or X3D XML parsers have to work --
because all implementations agree here what to do, and it wasn't easy
to get to this point. Instead, we have to fix the spec which is
confusing ( https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding
). Complicating the spec with additional rules, that are not
backward-compatible, is risky here.

    Please let's first just *fix* the current X3D XML spec (I propose
in my wiki improvements that we talked about many times now...)
without making any functional changes.

    Only afterwards, once we have a clear X3D XML spec about MFString
encoding (that reflects what the actual implementations *do*) then we
can think of adding new rules.

    Otherwise, we risk that we will complicate a part of X3D XML spec
text that is already confusing.

Regards,
Michalis

śr., 2 cze 2021 o 02:13 John Carlson <yottzumm at gmail.com> napisał(a):
>
> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org