[x3d-public] [x3d] X3D WG May 14 minutes : SFString in XML encoding examples

[vmarchetti at kshell.com]

This is a set of examples and proposed specification for XML encoding of SFString values by a rule that makes no reference to VRML encoding.

Michalis Kamburelis has determined that this is the SFString encoding rule applied by several current browsers: See https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding#background-discussion-about-backslashes <https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding#background-discussion-about-backslashes> 


[To review: Curly brackets are being used to isolate text; and are not part of the text content. All other characters inside curly brackets are  part of the text content,
and no escaping or unescaping is done  inside curly brackets ]


XML Encoding to X3D values examples

       XML Encoding                          SFString value
1.     {<MetadataSet name='items'/>}         {items}
2.     {<MetadataSet name='"items"'/>}       {"items"}
3.     {<MetadataSet name='ite"ms'/>}        {ite"ms}
4.     {<MetadataSet name='\items'/>}        {\items}
5.     {<MetadataSet name='"\"items"'/>}     {"\"items"}


SFString values to XML encodings examples:

        SFString          XML encoding
1.     {items}           {<MetadataSet name='items'/>}
2.     {"items"}         {<MetadataSet name='"items"'/>}
3.     {ite"ms}          {<MetadataSet name='ite"ms'/>}
4.     {\items}          {<MetadataSet name='\items'/>}
5.     {\"items}         {<MetadataSet name='\"items'/>}

Proposed specification prose:

The determination of an SFString value from the XML encoding in an XML attribute:

From the XML attribute text, determine the string referred to as normalized attribute value by the algorithm in Section 3.3.3 of the XML Recommentations document Edition 1. https://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize . The SFString value is identical to the normalized attribute value.



The reverse process, constructing a valid XML encoding for a determined SFString value, may be normatively specified as any XML text which gives the correct value on applying the XML specified procedure.  Informative prose may describe algorithms which achieve this end.

Vince Marchetti



> On May 16, 2021, at 7:40 PM, vmarchetti at kshell.com wrote:
> 
> This refers to item 3 of the minutes of the May 14 X3D WG meeting  minutes.
> 
> 
> At the May 14 X3D WG meeting we again addressed the long-standing problem of defining the XML encoding of the SFString data type in node fields, particulalarly when the SFString containg quote characters.  It was proposed  to do two related tasks:
> 1. Generate examples of XML encoding which clearly illustrate the correct encoding of these edge cases
> 2. Write specification prose text which can be unambiguously interpreted by developers in their implementations, to ensure interoperability.
> 
> A perennial issue in these discussions is that we're reasoning about text, in text. We usually use the quote characters to  isolate the text we are writing about -- that doesn't work here, because the quotes are critical part of our discussion. For that reason, in the scope of this document, I  use curly brackets to set off text examples. In the X3D specification the curly bracket characters cause no controversy, and I will not use any examples where curly brackets are part of the text values. So, if I were to say the the value of an X3D field of type SFString is {"Hello"}, I mean at least two things:
> 1. If this value gets put in an MFString value and passed to the X3D Text node, it will be rendered as 7 character glyphs.
> 2. In any language binding, the value is a 7 character string in the native string representation of that language.
> 
> I propose that our examples should illustrate both issues the X3D implementors face: reading an XML encoding of an SFString value and determing the correct data for their implementation environment, and generating a correct XML encoding of an arbitrary SFString value. As Michalis K has pointed, there are relatively few usages of SFString has a field type, but one important one is as the name field  in the Metadata nodes. So I will propose a set of decoding examples for determining the correct value of the name field in the  XML encodings of an empty MetadataSet node. The result SFString  for these examples should either be the value of the name field or the assertion that the XML encoding itself is not a syntactically valid encoding.
> 
> 
>        XML Encoding                          SFString value
> 1.     {<MetadataSet name='items'/>}         ---
> 2.     {<MetadataSet name='"items"'/>}       ---
> 3.     {<MetadataSet name='ite"ms'/>}        ---
> 4.     {<MetadataSet name='\items'/>}        ---
> 5.     {<MetadataSet name='"\"items"'/>}     ---
> 
> 
> The second set of examples should illustrate the encoding problem: To specify a correct XML encoding of the empty MetadataSet whose name field has the specified value. The XML encoding has multiple correct solutions because the XML format itself provides multiple representations  of the same XML attribute.
> 
> 
>         SFString          XML encoding
> 1.     {items}           ---
> 2.     {"items"}         ---
> 3.     {ite"ms}          ---
> 4.     {\items}          ---
> 5.     {\"items}         ---
> 
> A final part of this project is to prepare normative  prose that determines these example patterns and  can be applied to the general case.
> 
> 
> 
> Vince Marchetti
> 
> 
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210518/1d75c91d/attachment-0001.html>