[x3d-public] SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]

[Leonard Daly]

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.

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.

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.


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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170508/d954806d/attachment.html>