[x3d-public] MFString quoting [was: interesting sample]

[Michalis Kamburelis]

2017-04-26 1:47 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>> To make it CORRECT, write
>>
>> <Text string=' "blablah" ' />
>>
>> or
>>
>> <Text string='"blablah"' />
>>
>
> Using single quotes as outer quotes is legal,
>
>>
>> or
>>
>> <Text string=""blablah"" />
>>
>
> but using double quotes is not in X3D:
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString
>
> although it is legal in XML.
>
> However, most browser probably allow double quotes as outer quotes since
> they will just use a standard XML parser.
> I am not pretending to understand the motivation for this X3D rule.
>

I don't think the X3D disallows using double quotes to surround XML
attributes in X3D XML encoding. Indeed, the specification (
http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString
) does not show this as a valid example (it only shows using single
quotes to surround the XML attribute). But it also doesn't say it's
invalid.

I admit, I may be biased when reading this part of the specification,
because I think (like you) that it would be weird if the X3D
specification was limiting what is valid XML syntax. Probably everyone
uses some standard library to read XML files, and we don't know:

- What character in XML was used to surround XML attribute: single or
double quote.
- What characters in XML were used to express a visible double quote:
" or ".

And we don't want to know it, after all it's the purpose of a standard
XML parser to hide these details from the programmers working on a
higher level.

Indeed, it would be great if the X3D XML specification clarified this,
both by more prose and by showing more examples what is correct and
what is incorrect (like the examples in my previous mail). Reading the
thread from http://web3d.org/pipermail/x3d-public_web3d.org/2017-March/006145.html
, it seems that everyone agrees about what the specification *should*
mean (regardless of what it currently means), and this expectation
matches (all?) current implementations. So it would be great to
improve/fix the specification:)

Regards,
Michalis