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

[Roy Walmsley]

Hi,

Leonard put forward a proposal regarding SFString / MFString, during which
he cited an example which I reproduce below:

    <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>
    <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'd like to look more closely at each of this to gain further insights,
before introducing an example of my own. But before we start, let's remind
ourselves that in the MetadataString node, the "name" field is of type
SFString, and the "value" field is of type MFString.

Version 1:

    <MetadataString name='SimpleName' value='Single value' />

This is not valid X3D in accordance with the current standard ISO/IEC
19776-1:2015 for two reasons:
	a) The value for the  "name" field does not conform because it has
single quotes.
	b) The value for the "value" field does not conform because it has
only one set of single quotes.

Version 2:

    <MetadataString name='SimpleName' value="Single value" />

This is not valid X3D in accordance with the current standard ISO/IEC
19776-1:2015 for two reasons:
	a) The value for the  "name" field does not conform because it has
single quotes.
	b) The value for the "value" field does not conform because it has
only one set of double quotes.

The divergence for both of these versions is simply in the quotation marks.
If we assume that V4.0 is more liberal in accepting these variation, then
there is no significant impact on tools and encoding transformations. We can
also ask what would the DOM look like if this was part of an embedded X3D
scene in an HTML syntax web page. There would be a single MetadataString
element with attributes of "name" and "value".

Version 3:

    <MetadataString name='SimpleName'>
         <value>Single value</value>
    </MetadataString>

Now we have a major divergence from the existing standard. The "value" field
has been encoded as child content, and not an attribute. An HTML/XML parser
would expect that both "MetadataString" and "value" are to be loaded as DOM
elements. The "MetadataString" element has the attribute "name". The "value"
element is a child element of "MetadataString". While, of course, a parser
could be written to correctly interpret the intent, this does complicate it.

Now let's consider a validation tool such as the XML schema. Here is an
extract from V3.3 for the MetadataString node, with <xs:annotation> elements
removed for ease of readability:

	<xs:element name="MetadataString">
		<xs:complexType>
			<xs:complexContent>
				<xs:extension base="X3DNode">
					<xs:attribute name="name"
type="SFString"/>
					<xs:attribute name="reference"
type="SFString"/>
					<xs:attribute name="value"
type="MFString"/>
					<xs:attribute name="containerField"
type="metadataContainerFieldValues" default="metadata"/>
				</xs:extension>
			</xs:complexContent>
		</xs:complexType>
	</xs:element>

In this case, the content model is inherited from X3DNode, so this is also
reproduced:

	<xs:complexType name="X3DNode" abstract="true">
		<xs:sequence>
			<xs:element ref="IS" minOccurs="0"/>
			<xs:group ref="ChildContentModelCore"
minOccurs="0"/>
		</xs:sequence>
		<xs:attributeGroup ref="DEF_USE"/>
		<xs:attributeGroup ref="globalAttributes"/>
	</xs:complexType>

Consider the complexity of writing a schema that would not only validate
versions 1 and 2, but also version 3. Version 3 does not have the attribute
"value". You will also notice that X3DNode does not have the attribute
"metadata". In XML terms these are not attributes. Instead, the loader has
to read the child content and then, when the node is instantiated, add the
child content to the appropriate xFNode field, depending on the
"containerField" value for the child node content. Clearly, this type of
approach will cause significant problems for X3D validation.

Further, how does this approach relate to transformation from, say, the XML
encoding to the Classic VRML encoding? How does it affect the Compressed
binary encoding? Clearly considerable further work is needed to consider the
feasibility of this alternate encoding with respect to the overall X3D
product content.

Version 4 and subsequent:

These are variants of Version 3, so the same general comments apply.

Now, I introduce another simple example. Consider a Material node, encoded
in the style of version 3.

    <Material>
         <ambientIntensity>0.2</ambientIntensity>
         <diffuseColor>0.8 0.8 0.8</diffuseColor>
         <emissiveColor>0 0 0</emissiveColor>
         <shininess>0.2</shininess>
         <specularColor>0 0 0</specularColor>
         <transparency>0</transparency>
    </Material>

If this style of encoding is to be acceptable for xFString fields, the
presumable it should also be acceptable for all other field types.

My final thought for this posting is about CSS, which as a general topic has
not so far received much attention. What is the impact on CSS for this style
of encoding, compared to the current style using attributes?

All the best,

Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170510/5baf3942/attachment-0001.html>