<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I am going to attempt to answer the
questions posed by Don. If something is missing it was
inadvertently excluded. The proposed structure is extracted and
included here for easy of discussion:<br>
<br>
1:
<br>
<Node text="entity-encoded text"></Node>
<br>
<br>
OR
<br>
<br>
2:
<br>
<Node>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
</Node>
<br>
<br>
Where (1) is a single-valued string (either SFString or the first
element of an MFString)<br>
and (2) is an MFString with (in this listing) five elements.<br>
<br>
<br>
Q: Is such a redesign of the XML tree possible? <br>
A: This might be a rhetorical question as it was immediately
answered. Of course it is possible. There is nothing in XML that
would prohibit this proposed structure.<br>
<br>
Q: Are 2-way conversion mappings possible? <br>
A: I don't see why conversion from the existing V3.3 definition is
not mapable to this proposed definition. While I do not doubt that
there is a mapping backwards, I wonder why that would be pursued.1<br>
<br>
Q: What problem are you trying to fix? <br>
A: There were three reasons provided in the original proposal. I
will also add that this topic has generated numerous discussions
on the public and WG lists since it was first introduced in V3.0.
The rate of threads is (if memory is correct) about once per year.
After 15+ years of X3D V3, this rate of discussion (and the
extensive discussion in each occurrence) tells me that the
documentation is not sufficient. After 4 versions of the standard,
that tells me that it may not be possible to write sufficiently
clear documentation and that the better solution would be to
change the representation.<br>
<br>
Q: [wasn't specifically asked, but just used without comment]
Container fields.<br>
A: I think 'container' fields in many (maybe even in all) cases
were incorrect. V4 is an opportunity to correct that.<br>
<br>
Q: [not quite sure where the questions are in this] "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.
"<br>
A: The goal is not a flexible reusable container, but a clearer
way of representing the data.<br>
A: Not sure what is meant by "more code everywhere". Generally
using spell-out tag names and clear data structure makes clearer
code, documentation, and is less error-prone.<br>
A: I am not sure how it makes validation more complex -- I just
don't know enough to answer.<br>
A: Converters are going to need to change anyway, it might as well
be done all at once.<br>
A: It is not obvious that the "error surface" is increased<br>
<br>
Q: "Finally, not evident what you are trying to express with extra
| characters in <![CDATA|[ etc. "<br>
A: Those are not my typing. It was introduced by my email client
(Thunderbird) or some other point in the email from me to you. All
of the CDATA references should be the normal expression [remove
spaces between each character] <br>
< ! [ C D A T A [ contents-of-character-data ] ] ><br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:db40d42d-cbe7-beed-a3eb-642b2a13897e@nps.edu">On
5/8/2017 4:30 PM, Leonard Daly wrote:
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Our published agenda goals are:
<br>
- Primary discussion topic: SFString and MFString in the XML
encoding – which quotation marks should be accepted?
<br>
- Ancillary topic: MFxxxx fields – use of commas as value
separators
<br>
<br>
Of note is that
<br>
- Wording improvements have been proposed to improve the clarity
and precision of X3D XML Encoding prose.
<br>
- Some variability in XML can lead to slightly different syntax
but identical results.
<br>
- Full expressive power has been shown for any legal X3D data
representation, with multiple forms of XML validation.
<br>
- No apparent counterexample scenes have yet been identified.
Numerous archive examples are deeply tested.
<br>
- A variety of implementations for converting to various encodings
and language bindings are available.
<br>
<br>
Continuing with the new options you are posing...
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
As repeated on last Wednesday's teleconference, syntax for two
HTML5 encodings are appropriate exemplars:
<br>
<br>
HTML 5.1, W3C Recommendation, 1 November 2016
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html51">https://www.w3.org/TR/html51</a>
<br>
<br>
8. The HTML syntax
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html51/syntax.html#syntax">https://www.w3.org/TR/html51/syntax.html#syntax</a>
<br>
<br>
9. The XHTML syntax
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html51/xhtml.html#xhtml">https://www.w3.org/TR/html51/xhtml.html#xhtml</a>
<br>
<br>
which both map identically to the DOM:
<br>
<br>
3. Semantics, structure, and APIs of HTML documents
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html51/dom.html#dom">https://www.w3.org/TR/html51/dom.html#dom</a>
<br>
"Every XML and HTML document in an HTML user agent is
represented by a Document object. [DOM]"
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.).
<br>
<br>
Is such a redesign of the XML tree possible? Certainly, XML3D
does something quite similar by using elements to organize data
types.
<br>
<br>
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.
<br>
<br>
What problem are you trying to fix? Not clear (to me anyway).
<br>
<br>
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
<br>
<br>
<Coordinate>
<br>
<MFVec3f DEF="ReusableTriangle"
containerField="point">1.1 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8
9.9</MFVec3f>
<br>
<Coordinate>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
XML 1.0, W3C Recommendation, fifth edition
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/REC-xml/#syntax">https://www.w3.org/TR/REC-xml/#syntax</a>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/CDATA">https://en.wikipedia.org/wiki/CDATA</a>
<br>
<br>
X3D Resources: type Definitions -> CDATA
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/X3dTooltips.html#type">http://www.web3d.org/x3d/content/X3dTooltips.html#type</a>
<br>
<br>
<blockquote type="cite">For the purposes of this discussion, text
is a field either of type SFString or MFString.
<br>
<br>
New Syntax:
<br>
<br>
1:
<br>
<Node text="entity-encoded text"></Node>
<br>
<br>
OR
<br>
<br>
2:
<br>
<Node>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
<text>text-string</text>
<br>
</Node>
<br>
<br>
In (1) "entity-encoded text" is a single-valued string that is
either SFString of the first (and only) element of MFString.
<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html5/syntax.html#cdata-sections">https://www.w3.org/TR/html5/syntax.html#cdata-sections</a> 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.
<br>
<br>
If both an attribute and child elements are provided, the child
element has precedence.
<br>
<br>
<br>
<br>
Examples (using MetadataString node)
<br>
<br>
These five examples produce the same result
<br>
<MetadataString name='SimpleName' value='Single value'
/>
<br>
<MetadataString name='SimpleName' value="Single value"
/>
<br>
<MetadataString name='SimpleName'>
<br>
<value>Single value</value>
<br>
</MetadataString>
<br>
<MetadataString>
<br>
<name>SimpleName</name>
<br>
<value>Single value</value>
<br>
</MetadataString>
<br>
<MetadataString>
<br>
<name>SimpleName</name>
<br>
<value>|<![CDATA[|Single
value]]></value>
<br>
</MetadataString>
<br>
<br>
Multi-valued 'value' field examples
<br>
<MetadataString name='SimpleName'>
<br>
<value>|<![CDATA||[First
element|]]></value>
<br>
</MetadataString>
<br>
<MetadataString>
<br>
<value>|<![CDATA||[First
element|]]></value>
<br>
<name>SimpleName</name>
<br>
<value>||<![CDATA|[Second
element|]]></value>
<br>
</MetadataString>
<br>
<MetadataString>
<br>
<name><![CDATA["C'mplx
\Element]]></name>
<br>
<value>Easy String</value>||||
<br>
<value>|<![CDATA||[A string with "'s ''s
&'s and <> in it.]]></value> |
<br>
</MetadataString>
<br>
<br>
<br>
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.
<br>
<br>
Why:
<br>
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'.
<br>
2) It is clear how to properly encode multi-element strings.
<br>
3) Strings containing characters that are normally thought of as
meta-characters (e.g., backslash, ampersand, angle-brackets,
etc.) have a straight-forward representation.
<br>
<br>
Summary:
<br>
1) Provide an attribute value for simple entry for either
SFString of the first and only element of an MFSting.
<br>
2) Multi-valued MFString are represented using child elements
<br>
3) Complex strings (either SFString or MFString) are entered
using child elements
<br>
<br>
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
<br>
<br>
<Coordinate>
<br>
<point>x1 y1 z1[,] x2 y2 z2[,] ...[,] xN yN
zN</point>
<br>
</Coordinate>
<br>
<br>
<br>
-- <br>
*Leonard Daly*
<br>
3D Systems & Cloud Consultant
<br>
LA ACM SIGGRAPH Chair
<br>
President, Daly Realism - /Creating the Future/
<br>
<br>
<br>
_______________________________________________
<br>
x3d mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:x3d@web3d.org">x3d@web3d.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d_web3d.org">http://web3d.org/mailman/listinfo/x3d_web3d.org</a>
<br>
<br>
</blockquote>
<br>
<br>
all the best, Don
<br>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>