[x3d-public] Minutes of X3D WG Open Meeting; X3D v4 XML syntax can match HTML5 design and DOM

Wed May 17 04:35:46 PDT 2017

On 5/16/2017 8:18 PM, Leonard Daly wrote:
> At some point in the discussion of singles & doubles, I ask as to the applicability of these discussions to the current V3.x standard or a future V4.x standard. It was answered that the discussion was for V3.x.
> 
> Leonard Daly

[Here is a long-form explanation of the point which hopefully is considered useful.]

The representation of SFString and MFString attribute values in the X3D version 3.3 XML encoding also has direct bearing on how SFString and MFString attribute values can be applied in X3D v4.

X3D version 3.3 XML encoding is found at

	http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/X3D_XML.html

It seemed like we had excellent conceptual resolution of several tricky issues last week.  Dialog is certainly helpful.  It will be good to see last week's careful refinements consistently elaborated in Mantis, in specification prose and in validation diagnostic tests.

This improved clarity on inclusion of X3D SFString/MFString content within a single-quoted or double-quoted attribute value is helpful for all X3D v3 versions as well as X3D v4.  No problems expected with backward compatibility of existing content.  No problems foreseen with prospective HTML5 representations of such attribute values in either an HTML (loose) or XHTML (strict) encodings.

	HTML5.1, Section 8. The HTML syntax
	https://www.w3.org/TR/html51/syntax.html#syntax

8.1.2. Elements, last paragraph.
"Tags contain a tag name, giving the element’s name. HTML elements all have names that only use alphanumeric ASCII characters. In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element’s tag name; tag names are case-insensitive."

	HTML5.1, Section 9. The XHTML syntax
	https://www.w3.org/TR/html51/syntax.html#syntax

First paragraphs.
"The syntax for using HTML with XML, whether in XHTML documents or embedded in other XML documents, is defined in the XML and Namespaces in XML specifications. [XML] [XML-NAMES]
This specification does not define any syntax-level requirements beyond those defined for XML proper."

So: case insensitive, or strict case, equivalently.

It is not hard to apply Section 8 HTML Syntax to the X3D tagset.  Aligning with the HTML5 recommendations for each syntax also aligns us with the DOM: both at the specification level, and also for implementations that conform to HTML (essentially all of them).  Always worth remembering is that the major HTML5 design decision that overcame all issues regarding loose/strict content were resolved by placing the DOM foremost for HTML5 semantics, then showing how each syntax aligns to it.  The HTML Recommendation actually points this out...

*Recommended reading for everyone* follows:

HTML 5.1, Section 1.6. HTML vs XHTML

https://www.w3.org/TR/html51/introduction.html#html-vs-xhtml
============================================================
This section is non-normative.

This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.

The in-memory representation is known as "DOM HTML", or "the DOM" for short.

There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.

The first such concrete syntax is the HTML syntax. This is the format suggested for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with the text/html MIME type, then it will be processed as an HTML document by Web browsers. This specification defines the latest version of the HTML syntax, known as "HTML 5.1".

The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines the latest version of the XHTML syntax, known as "XHTML 5.1".

The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XHTML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XHTML syntaxes.
============================================================

The last paragraph above refers to some legacy HTML edge cases that are not blockers for HTML5 and do not seem applicable to X3D.

So, once again, HTML syntax and XHTML syntax both map to DOM.  Thus it seems completely clear that a pair of X3D syntaxes can be compatible with DOM HTML, just as a pair of HTML syntaxes can be compatible with DOM HTML.

The .x3d models in the X3D Example Archives illustrate this pair of encoding syntaxes already, with corresponding conversions to loose HTML syntax (Cobweb) or strict XHTML syntax (for X3DOM).

	http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples (3896 total X3D scenes)

	http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldIndex.html
	http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.x3d

	http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldCobweb.html
	http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldX3dom.xhtml

Further testing will always be good.  Meanwhile no counterexamples yet found that preclude lower-case (or case insensitive) syntax adaptations of existing X3D XML.  Indeed most examples on the X3DOM site follow that preference.

	https://www.x3dom.org

<x3d width='500px' height='400px'>
     <scene>
         <shape>
             <appearance>
                 <material diffuseColor='1 0 0'></material>
             </appearance>
             <box></box>
         </shape>
     </scene>
</x3d>

Similarly, Cascading Stylesheets (CSS) for HTML operate on the DOM tree, so CSS capabilities for X3D v4 are also expected to align at the same time.  Good topic for separate analysis and discussion.

Since DOM events change attributes on elements, and since routed X3D events change fields on nodes, and since our X3D XML encoding design matches elements to nodes (and attributes to simple-type fields), content can be unambiguously defined that might work one way or the other.  We will need to define how they can coherently co-exist at run-time, quite similarly as we did in years past when specifying the External Access Interface (EAI).  Once again, patterns for success exist for this harmonization.

Aligning with HTML5 and DOM is of course our primary goal for X3D v4.  DOM events and CSS come along for the ride.  Closer and closer!

A good topic for discussion during the upcoming Web3D 2017 Conference and future teleconferences will be how to best document both HTML syntaxes as well as DOM programming in the family of X3D specifications. Perhaps a single X3D specification document, perhaps matched additions to the existing X3D specifications, perhaps something else.

	http://www.web3d.org/standards
	http://www.web3d.org/strategy
	http://www.web3d.org/specifications/X3dSpecificationRelationships.png

As technical mysteries steadily keep getting resolved through example implementation and evaluation, it becomes easier to align the specification of excellent new features to best effect.

"Measure twice cut once" is the carpentry saying, seems apropos for us as well.  All discussion and improvements are welcome.

v/r Don

>> Attendees:  Roy Walmsley, Leonard Daly, Anita Havele, Vince Marchetti, Don Brutzman, Dick Puk, Michalis Kamburelis,
>>
>> Apologies received:
>>
>> =======================================================================================================
>>
>> Preliminary: *_Welcome, and introductions, as necessary_*
>>
>> Roy welcomed everyone. No introductions were needed.
>>
>> =======================================================================================================
>>
>> Primary discussion topic: *_SFString and MFString in the XML encoding – which quotation marks should be accepted?_*
>>
>> Ancillary topic: *_MFxxxx fields – use of commas as value separators_*
>>
>> *__*
>>
>> ·Introduction: Review of current and reference standards, led by the meeting chair
>>
>> oISO/IEC 19775-1:2013 clause 5.3.14 SFString and SFString (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.html#SFStringAndMFString)
>>
>> oISO/IEC 19776-2:2015 clause 5.1.2 Description (http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#Description)
>>
>> oISO/IEC 19776-2:2015 clause 5.15 SFString and MFString (http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFString)
>>
>> oISO/IEC 19776-2:2015 clause A.4 Fields (http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Fields)
>>
>> oIntroducing JSON (http://www.json.org/)
>>
>> oISO/IEC 19776-1:2015 clause 5.1.2 Description (http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#5.1.2)
>>
>> oISO/IEC 19776-1:2016 clause 5.15 SFString and MFString (http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString)
>>
>> oHTML 5.1 W3C Recommendation, 1 November 2016, clause 8.1.2.3 Attributes (https://www.w3.org/TR/html/syntax.html#elements-attributes)
>>
>> oHTML 5.1 W3C Recommendation, 1 November 2016, clause 9.1 Writing XHTML documents (https://www.w3.org/TR/html/xhtml.html#writing-xhtml-documents)
>>
>> oExtensible Markup Language (XML) 1.1 W3C Recommendation 4 February 2004, clause 2.3 Common Syntactic Constructs [10] AttValue (https://www.w3.org/TR/2004/REC-xml11-20040204/#NT-AttValue)
>>
>> Roy opened the discussion with a short review of each of the above references. The reference from ISO/IEC 19775-1 did not have specific impact on the discussions. The next three references from ISO/IEC 19776-2, the Classic VRML encoding, define a string to be have double quotation marks (“), and MFStrings to be an array of strings enclosed in square brackets as array delimiters. Furthermore, an MFString with a single element does not require the square brackets. This principle, of not requiring square brackets for a single value, applies to all MFxxxx fields. The next two references, from ISO/IEC 19776-1, the XML encoding, define a string to have double quotation marks(“) and MFStrings to be an array of strings in single quotes (‘). The remaining three HTML and XML references define attribute values to be enclosed in either double quotes(“) or single quotes(‘).
>>
>> Don highlighted the existing Mantis issue on this topic that collects some comments. This is issue 1091 - http://www.web3d.org/member-only/mantis/view.php?id=1091 – entitled “Confusion between XML and X3D syntax for SFString”. The related Mantis issues 705 - http://www.web3d.org/member-only/mantis/view.php?id=705 – entitled “Escaping backslashes” and 488 - http://www.web3d.org/member-only/mantis/view.php?id=488 – entitled “Handling of quotation marks” were also noted.
>>
>> Need to be careful with specifying what we mean by “double quotes” and “single quotes” or “apostrophes”. See https://www.w3.org/TR/REC-xml/#sec-common-syn and https://dev.w3.org/html5/html-author/charref for XML standard. Michalis provided references to clarify this – see http://web3d.org/pipermail/x3d-public_web3d.org/2017-May/006674.html.
>>
>> The question was also raised about whether the requirement in the XML encoding for an MFString with a single value to be encoded using two sets of quotation marks could be relaxed, in effect dropping the outer set of quotes, just as the Classic VRML encoding drops the array square brackets.
>>
>> The need for backslash escaping was described. They are needed in the XML encoding because there is both an XML parser and an X3D parser. The question of whether there should be a difference between SFString and MFString escaping requirements was raised. Michalis reported that some implementations do not recognize escape sequences in SFString values – see http://web3d.org/pipermail/x3d-public_web3d.org/2017-May/006690.html.
>>
>> Michalis noted that the X3D XML encoding is specific about what quotation marks to use, compared to XML. He suggested X3D should permit either sets of quotes, to match the XML / HTML standards. There was general agreement that the specific X3D requirements should be relaxed to match the XML specification for string attributes.
>>
>> It was agreed that escape sequences are indeed required for MFStrings, but are not be required for SFStrings.
>>
>> It was proposed that alternative text for clause 5.15 in ISO/IEC 19776-1 should be written. During the discussion, there was a large number of e-mail exchanges on the public list, all stemming from the meeting agenda at http://web3d.org/pipermail/x3d-public_web3d.org/2017-May/006643.html. At the end of the meeting discussions Don and Michalis agreed to put forward new text for consideration.
>>
>> =======================================================================================================
>>
>> Close of Meeting: *_Thanks for participating and contributing_*
>>
>> *__*
>>
>> Roy thanked everyone for their time to participate and the passionate contributions to the debate.
>>
>> *__*
>>
>> Roy Walmsley
>>
>> X3D WG co-chair
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 
> 
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

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