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

[Michalis Kamburelis]

2017-04-26 16:10 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>
>
> On Apr 25, 2017 11:16 PM, "Michalis Kamburelis"
>
> So
>
>   " ' MFString or SFString ? ' "
>
> is either
> - an incorrect MFString (you cannot use ' to delimit parts within MFString)
>
>
> Yes, you are right, that is incorrect. But that brings up SFStrings.
>
> When not used as part of an MFString, they still have the double quote
> requirement while XML allows both single or double quotes.

Indeed, the specification sentence

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

could be changed to

""""
  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"'
""""

>
> So, I would suggest to allow single quotes as delimiters in MFStrings as
> well although I realize that places an additional burden on the x3d parser.
>
> In the end, to me, allowing balanced pairs of single or double quotes
> interchangeably anywhere is the simplest rule. Backslash escaping for
> printing is required in any case.
>

I would find it useful too. But this is a different change to the
spec, and one that is not so 100% secure.

1. In a perfect world, it should be possible to add this possibility
to the specification, because

  " 'one' 'two' "

is an an invalid MFString now. So the new X3D XML readers could see
that "oh, it starts with an apostrophe, it must be an MFString using
that new feature of enclosing parts in apostrophes". Unfortunately,
because of a large number of incorrect X3D examples on the Internet,
most X3D XML right now check whether the string starts and ends with
double-quotes, and if not -- they assume it's an invalid MFString, and
parse it as SFString, and use the contents as an MFString with count =
1.

So

  <Text string=" 'blahblah' " />

right now causes the display of apostrophes (and a warning in the
console). After your change, it would be displayed without
apostrophes.

True, it will probably not affect much scenes in practice... Still,
it's not a 100% secure change. Unlike the initial idea of only fixing
the spec to conform to XML to allow the whole XML attribute be
surrounded by ' or " .

2. As Yves notes, the current rule is also consistent with classic
encoding (and VRML). Right now, my MFString handling in view3dscene is
just firing up a VRML lexer to interpret the MFString attribute
contents. With your change, we either also change the classic
encoding, or we need a little different code to handle MFString in XML
encoding.

Neither 1. or 2. are a large disadvantage in my eyes, so I'm not
refusing this change. I'm only saying that it's a little more
intrusive change than the simpler plan to "just fix the specification
to allow what XML allows".

>> Backslash escaping for printing is required in any case.
>
> I don't understand that part.

If I may, I think I can explain what Andres meant:

You must already use double backslashes to get a single visible
backslash in MFString. After the Andreas proposed change, you would
need to protect single-quotes (apostrophes) by backslashes, but that's
not a problem (it does not cause an incompatibility for correct X3D
scenes), because all the backslashes in current X3D scenes are either
doubled (to mean a single backslash) or they are used to protect the
following character.

Consider this example:

  <Text string=""here is \'text surrounded in apostrophes\'"" />

Right now it's either incorrect (if you don't think that backslash
before apostrophe is valid) or correct (and no backslashes will be
visible).

After the proposed Andreas change, this example will always be correct
(and no backslashes will be visible), since then the apostrophes will
need to be (in some situations) protected. So, no compatibility was
broken.

Regards,
Michalis