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

[Leonard Daly]

[Comments embedded]


> RE: SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]
>
> 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 ofthisto 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:2015for two reasons:
>
> a) The value for the  "name" field does not conform because it has 
> single quotes.
>

Actually, it is not valid X3D V3.x because the string value is not 
enclosed in double quotes ("). The valid X3D V3.x fragment would be

    name='"SimpleName"'

See second sentence of 
http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString



> 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:2015for two reasons:
>
> a) The value for the  "name" field does not conform because it has 
> single quotes.
>

See above


> b) The value for the "value" field does not conform because it has 
> only one set ofdoublequotes.
>

Not really. For a single element MFString and SFString look the same. 
The value needs to be enclosed in double quotes. This (double-quoted 
string) is the value of the attribute, so it needs to be enclosed in any 
of the XML quoting characters (even though the spec is wrong on this 
point). This additional quoting may cause characters in the attribute's 
value to change representation (e.g., " to ")


> The divergencefor both of these versionsis simply in the quotation 
> marks. If we assume that V4.0is more liberal in accepting 
> thesevariation, thenthere 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 
> theattribute “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 avalidation 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:elementname="MetadataString">
>
> <xs:complexType>
>
> <xs:complexContent>
>
> <xs:extensionbase="X3DNode">
>
> <xs:attributename="name"type="SFString"/>
>
> <xs:attributename="reference"type="SFString"/>
>
> <xs:attributename="value"type="MFString"/>
>
> <xs:attributename="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:complexTypename="X3DNode"abstract="true">
>
> <xs:sequence>
>
> <xs:elementref="IS"minOccurs="0"/>
>
> <xs:groupref="ChildContentModelCore"minOccurs="0"/>
>
> </xs:sequence>
>
> <xs:attributeGroupref="DEF_USE"/>
>
> <xs:attributeGroupref="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 theappropriate 
> xFNode field, depending on the “containerField” value for the child 
> node content. Clearly, this type of approach will cause significant 
> problemsfor X3D validation.
>

While I am not an expert at validation, I don't think this is really an 
issue. To illustrate this I wish to point out the W3C validator for HTML 
and XHTML. These support the (structured) HTML content for tables, 
lists, definitions, and many other nested tags. I fail to see why making 
things clearer to read makes it harder to validate.


> 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 furtherwork is needed 
> to consider the feasibility of this alternate encoding with respect to 
> the overall X3D product content.
>

My underlying motivation is that a single-nested structure in XML is 
equivalent to an array. This makes the connection between the 
human-readable expression of the content (e.g., XML) and its internal 
form easier and more obvious. Once stored internally, exporting to other 
representations should be as easy (and perhaps easier) than reading in 
those other representations.




> *_Version_**_4 and subsequent_**_:_*
>
> These are variants of Version 3, so the same general comments apply.
>
> Now, I introduce anothersimpleexample.Consider aMaterial 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.
>


Note that the discussion topic was specifically for strings. I very 
explicitly did not discuss this type of example. While Roy's reasoning 
seems reasonable, it can lead to some unpractical examples (e.g., 
transparency). I just addressed strings because I feel that X3D needs to 
allow the use of CDATA to make things easier to handle.


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

The concept of CSS is to allow the separation of content from style. In 
the example just above, the (existing) fields of a Material node are 
separated out into children. It is possible to argue that the these 
fields are the content of a Material node. But from the perspective of a 
Shape node, all material fields are styles to the defined geometry. A 
bit more deeper thinking on this topic before any decision can be 
approached.


-- 
*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/20170510/190d2573/attachment-0001.html>