We have talked about it on the X3D mailing list and teleconference. I believe we have a consensus what is the proper solution (clarification) to the specification.

Table of Contents:

• Proposed change to clarify quoting
• Proposed change to clarify backslashes use
• Background: Discussion about backslashes:

The proposed change to the specification (all to the section http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString ) would be to change this part:

  The MFString specifies zero or more SFStrings enclosed in single
quotes (e.g., '"string1" "string2"').

  NOTE  The construct

"string3"

is not a valid instance of an MFString. Such an MFString would be
properly specified as

'"string3"'

into this:

  The MFString specifies zero or more SFStrings, with each single
string enclosed in double quotes (e.g., "string1" "string2"). Note
that inside an XML attribute, you have to express a double quote using
the " character entity, unless you enclose a whole XML attribute
in single quotes.

  NOTE  The construct

"string3"

is not a valid instance of an MFString. Such an MFString would be
properly specified as

'"string3"'

or

'"string3"'

or

""string3""

For additional clarity, I would also add more prose and examples to explain when backslashes are needed. So I would change

EXAMPLE 2  Two instances of the double quote are contained in the
following SFString field string:

<Text string='"He said, \&quot;Immel did it!\&quot;"' />

with this:

If a string is part of an MFString, and you want this string to
contain a double-quote (for example, to actually show a double-quote
using the Text node field "string") then you have to place a backslash
before this double-quote. This rule applies regardless if you express
double-quote as " or as " . This is necessary, to avoid treating
the double-quote as a delimiter of strings on a MFString list.

Consequently, if you want a string inside MFString to contain a
backslash (for example, to actually show a backslash using the Text
node field "string") then you have to write two backslashes. This is
necessary, to avoid accidentally changing the meaning of a following
double-quote character.

EXAMPLE 2  All the following forms are correct and equivalent:

<Text string='"He said, \"Immel did it!\""' />

<Text string='"He said, \&quot;Immel did it!\&quot;"' />

<Text string='&quot;He said, \&quot;Immel did it!\&quot;&quot;' />

<Text string="&quot;He said, \&quot;Immel did it!\&quot;&quot;" />

Moreover this:

  SFString specifies a single string encoded as a sequence of UTF-8
octets enclosed in double quotes (e.g., "string").

could be changed to this:

  SFString specifies a single string encoded as a sequence of UTF-8
octets. It is simply the value of an XML attribute. As such, following
XML rules, it can be surrounded either in single-quotes (apostrophes)
or double quotes.

The following examples of an SFString are all valid:

"string"
'string'
"string "with some quotes inside""
'string "with some quotes inside"'
'string "with some quotes inside"'

(from my mail Backslashes in X3D XML in SFString)

Short version: I tested how do the existing X3D browsers treat backslashes in SFString and MFString in X3D XML encoding. The results are conclusive:

• backslashes are NOT used for escaping inside SFString
• backslashes are used for escaping inside MFString

This confirms my suggestions during today's Web3D teleconference. SFString and MFString in XML encoding do not treat the backslash the same way (at least in current implementations). So if we want to fix the specification such that it matches the current implementations -> we should preserve this.

My suggested corrections above account for this: they explicitly say that backslashes are only for MFString.

The tests and screenshots are on https://github.com/michaliskambi/x3d-tests/tree/master/backslashes_in_xml_encoding

Longer version:

During the talk today at Web3D Teleconference, we discussed the use of backslashes inside X3D XML MFString and SFString.

Background:

The X3D XML specification ( http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString ) unfortunately doesn't say much about backslashes. It only shows an example

  <Text string='"He said, \&quot;Immel did it!\&quot;"' />

To confuse matters more, the above example in X3D XML spec is titled "[...] the following SFString field string:" but it's obviosuly an MFString example (because Text.string is in fact MFString, and because there are additional double-quotes without backslashes inside).

OK, regardless of what does the specification say, what do the implementations do?

1. Everyone agrees that backslashes are necessary in X3D XML for MFString. Otherwise, when reading MFString value, you don't know whether some double-quote should be visible, or whether it's a delimiter that ends this part of MFString.

   Testing on:

   • FreeWRL
   • Instant Reality
   • BS Contact
   • Octaga Player
   • View3dscene (my own)

   All these browsers honor the backslashes as expected... except Octaga.

   But Octaga displays a weird characters here (see https://github.com/michaliskambi/x3d-tests/blob/master/backslashes_in_xml_encoding/screenshots/octaga_1.png ). I think we can safely say that this is just some bug in Octaga, and ignore Octaga for this test.

2. The interesting question is whether backslashes are used (as an escape character) in X3D XML for SFString.

   • On one hand, it would seem consistent, to have the same rule about backslashes for SFString and MFString.
   • On the other hand, they are not necessary for SFString (no need to escape double-quotes inside SFString in X3D XML). So the X3D browser can just "take" the value of the XML attribute as an SFString value.

   I proposed to check what the existing specifications are doing.

   The testcase isn't trivial. Existing X3D nodes use mostly MFString for a "free text" (URLs, or for Text.string). The SFString is mostly used only for "enumerated" fields where a limited set of values is valid. So I implemented a testcase using a Script node, that takes two SFString values, and sends them into the Text.string (which is of MFString type).

   The results of this testcase on

   • FreeWRL
   • Instant Reality
   • BS Contact

   are consistent, and show that the backslashes were NOT interpreted as escape characters inside SFString.

   The result of my view3dscene on this testcase is not useful (as I don't support JavaScript now, only CastleScript and Object Pascal). But I know that my implementation is consistent with the above: backslashes in SFString (in X3D XML) are NOT for escaping.

   The result of Octaga on this testcase is not useful, because it only shows more weirdness.

Please feel free to test my testcase on other browsers.

This was all tested on the latest versions of mentioned browsers, downloaded today, on 64-bit Windows.