[x3d-public] [x3d] SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]
Don Brutzman
brutzman at nps.edu
Mon May 8 20:03:25 PDT 2017
On 5/8/2017 4:30 PM, Leonard Daly wrote:
> The open discussion this week is what to do about SFString and MFString encodings. This is for V4 of the X3D Standard as V3.3 is already set and there is no planned work on >V3.3.
Our published agenda goals are:
- 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
Of note is that
- Wording improvements have been proposed to improve the clarity and precision of X3D XML Encoding prose.
- Some variability in XML can lead to slightly different syntax but identical results.
- Full expressive power has been shown for any legal X3D data representation, with multiple forms of XML validation.
- No apparent counterexample scenes have yet been identified. Numerous archive examples are deeply tested.
- A variety of implementations for converting to various encodings and language bindings are available.
Continuing with the new options you are posing...
> The major discussion is for the XML/HTML (including XHTML) encoding as neither the ClassicVRML not Compressed Binary encodings have not generated discussions on any of the lists. There is also application of the (currently not standardized) JSON encoding.
As repeated on last Wednesday's teleconference, syntax for two HTML5 encodings are appropriate exemplars:
HTML 5.1, W3C Recommendation, 1 November 2016
https://www.w3.org/TR/html51
8. The HTML syntax
https://www.w3.org/TR/html51/syntax.html#syntax
9. The XHTML syntax
https://www.w3.org/TR/html51/xhtml.html#xhtml
which both map identically to the DOM:
3. Semantics, structure, and APIs of HTML documents
https://www.w3.org/TR/html51/dom.html#dom
"Every XML and HTML document in an HTML user agent is represented by a Document object. [DOM]"
> I am publishing this ahead of time so people can think about this proposal and contributed even if they cannot make the call on Wednesday.
Regarding your changes below, the design seems based on type names which remains quite different from the existing encodings which are based on field names, with typing implicit (defined in specification, schemas, etc.).
Is such a redesign of the XML tree possible? Certainly, XML3D does something quite similar by using elements to organize data types.
Are 2-way conversion mappings possible? I'd expect so, otherwise the representation isn't complete. X3D Object Model now provides an unambiguous baseline for that which matches X3D Abstract Specification type definitions and semantics.
What problem are you trying to fix? Not clear (to me anyway).
Might a hybrid be useful? Conceivably... for a special case. For example, when some geometry nodes have large index arrays or value arrays, those aren't always easy to adapt DEF/USE constructs into different roles. Perhaps elements corresponding to X3D field types might be a useful alternative encoding when building large scenes - similar to your <Coordinate><point> example but maybe more general like
<Coordinate>
<MFVec3f DEF="ReusableTriangle" containerField="point">1.1 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8 9.9</MFVec3f>
<Coordinate>
Am thinking that if you really want a data holder for flexible re-use, then using existing X3D datatype names makes more sense than a role-based name. But major concerns immediately appear. Such an approach adds more code everywhere, and more complex validation, and changes to converters, and a much greater potential-error surface. So we'd probably need to be very sparing with it... but it would be possible to list some example cases that might be improved (not fixed), so tradeoff evaluation is conceivable.
Finally, not evident what you are trying to express with extra | characters in <![CDATA|[ etc. CDATA character-data blocks are the specified XML mechanism to allow chunks of text that do not have to be parsed as XML and instead remain as unmodified plain text. For example, X3D Script nodes often contain a CDATA block, which in turn holds Javascript source, which in turn can include constructs like a = (b < c) && (d > e); without modification. Of course CDATA is a document convenience only, not a new form of information. Identical documents might use or not use CDATA blocks without error. I expect you will also find that the choice of whether to use a CDATA block is optional by each user-agent program - thus, similar to ordering of attributes in plain XML, the author has no choice about whether the XML gets equivalently modified once it is sent.
XML 1.0, W3C Recommendation, fifth edition
https://www.w3.org/TR/REC-xml/#syntax
https://en.wikipedia.org/wiki/CDATA
X3D Resources: type Definitions -> CDATA
http://www.web3d.org/x3d/content/X3dTooltips.html#type
> For the purposes of this discussion, text is a field either of type SFString or MFString.
>
> New Syntax:
>
> 1:
> <Node text="entity-encoded text"></Node>
>
> OR
>
> 2:
> <Node>
> <text>text-string</text>
> <text>text-string</text>
> <text>text-string</text>
> <text>text-string</text>
> <text>text-string</text>
> </Node>
>
> In (1) "entity-encoded text" is a single-valued string that is either SFString of the first (and only) element of MFString.
>
> In (2) the element content of <text> is character string that conforms to the rules of HTML/XHTML/XML (uses HTML-entities). These may be CDATA sections (see https://www.w3.org/TR/html5/syntax.html#cdata-sections for justification for HTML) to support cross-document type compatibility (between HTML, XHTML, and XML). If 'text' is an SFString only the first child is allowed (in XML) or considered (in HTML). If 'text' is an MFString, then each <text> child contains one element and the elements are used in order.
>
> If both an attribute and child elements are provided, the child element has precedence.
>
>
>
> Examples (using MetadataString node)
>
> These five examples produce the same result
> <MetadataString name='SimpleName' value='Single value' />
> <MetadataString name='SimpleName' value="Single value" />
> <MetadataString name='SimpleName'>
> <value>Single value</value>
> </MetadataString>
> <MetadataString>
> <name>SimpleName</name>
> <value>Single value</value>
> </MetadataString>
> <MetadataString>
> <name>SimpleName</name>
> <value>|<![CDATA[|Single value]]></value>
> </MetadataString>
>
> Multi-valued 'value' field examples
> <MetadataString name='SimpleName'>
> <value>|<![CDATA||[First element|]]></value>
> </MetadataString>
> <MetadataString>
> <value>|<![CDATA||[First element|]]></value>
> <name>SimpleName</name>
> <value>||<![CDATA|[Second element|]]></value>
> </MetadataString>
> <MetadataString>
> <name><![CDATA["C'mplx \Element]]></name>
> <value>Easy String</value>||||
> <value>|<![CDATA||[A string with "'s ''s &'s and <> in it.]]></value> |
> </MetadataString>
>
>
> I made all of the node examples in fixed-width font to help ensure things are correctly represented. Many of the element values use CDATA sections.
>
> Why:
> 1) This brings the representation in line with HTML and XML representations of structure elements. For example the HTML element 'table' uses 'tr' and 'td' to ground information by rows and cells within the row, the structure of a table is not contained in attributes of 'table'.
> 2) It is clear how to properly encode multi-element strings.
> 3) Strings containing characters that are normally thought of as meta-characters (e.g., backslash, ampersand, angle-brackets, etc.) have a straight-forward representation.
>
> Summary:
> 1) Provide an attribute value for simple entry for either SFString of the first and only element of an MFSting.
> 2) Multi-valued MFString are represented using child elements
> 3) Complex strings (either SFString or MFString) are entered using child elements
>
> I do not advocate the approach of creating a separate child for each element of a numeric data types (e.g., PixelTexture, Coordinate, etc.); however, I do think that moving all the attribute string to the value of a single child element is a good idea. For example
>
> <Coordinate>
> <point>x1 y1 z1[,] x2 y2 z2[,] ...[,] xN yN zN</point>
> </Coordinate>
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_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
More information about the x3d-public
mailing list