<div dir="ltr">Michalis, thanks for taking the time to explain the issues more clearly.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 26, 2017 at 10:55 AM, Michalis Kamburelis <span dir="ltr"><<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2017-04-26 16:10 GMT+02:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>>:<br>
><br>
><br>
> On Apr 25, 2017 11:16 PM, "Michalis Kamburelis"<br>
><br>
> So<br>
><br>
> " ' MFString or SFString ? ' "<br>
><br>
> is either<br>
> - an incorrect MFString (you cannot use ' to delimit parts within MFString)<br>
><br>
><br>
> Yes, you are right, that is incorrect. But that brings up SFStrings.<br>
><br>
> When not used as part of an MFString, they still have the double quote<br>
> requirement while XML allows both single or double quotes.<br>
<br>
Indeed, the specification sentence<br>
<br>
""""<br>
SFString specifies a single string encoded as a sequence of UTF-8<br>
octets enclosed in double quotes (e.g., "string").<br>
""""<br>
<br>
could be changed to<br>
<br>
""""<br>
SFString specifies a single string encoded as a sequence of UTF-8<br>
octets. It is simply the value of an XML attribute. As such, following<br>
XML rules, it can be surrounded either in single-quotes (apostrophes)<br>
or double quotes.<br>
<br>
The following examples of an SFString are all valid:<br>
<br>
"string"<br>
'string'<br>
"string "with some quotes inside""<br>
'string "with some quotes inside"'<br>
'string "with some quotes inside"'<br>
""""<br>
<br>
><br>
> So, I would suggest to allow single quotes as delimiters in MFStrings as<br>
> well although I realize that places an additional burden on the x3d parser.<br>
><br>
> In the end, to me, allowing balanced pairs of single or double quotes<br>
> interchangeably anywhere is the simplest rule. Backslash escaping for<br>
> printing is required in any case.<br>
><br>
<br>
I would find it useful too. But this is a different change to the<br>
spec, and one that is not so 100% secure.<br>
<br></blockquote><div><br></div><div>Yes, this would be a bigger change but perhaps worth it ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. In a perfect world, it should be possible to add this possibility<br>
to the specification, because<br>
<br>
" 'one' 'two' "<br>
<br>
is an an invalid MFString now. So the new X3D XML readers could see<br>
that "oh, it starts with an apostrophe, it must be an MFString using<br>
that new feature of enclosing parts in apostrophes". Unfortunately,<br>
because of a large number of incorrect X3D examples on the Internet,<br>
most X3D XML right now check whether the string starts and ends with<br>
double-quotes, and if not -- they assume it's an invalid MFString, and<br>
parse it as SFString, and use the contents as an MFString with count =<br>
1.<br>
<br>
So<br>
<br>
<Text string=" 'blahblah' " /><br>
<br>
right now causes the display of apostrophes (and a warning in the<br>
console). After your change, it would be displayed without<br>
apostrophes.<br></blockquote><div><br></div><div>Right now, it would be invalid. Browsers would typically just receive 'blahblah' from the xml parser as value.</div><div>They may or may not decide to display the apostrophes or anything at all.</div><div>After my change, it would be displayed without apostrophes which I think would be the expectation by most.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
True, it will probably not affect much scenes in practice... Still,<br>
it's not a 100% secure change. Unlike the initial idea of only fixing<br>
the spec to conform to XML to allow the whole XML attribute be<br>
surrounded by ' or " .<br>
<br>
2. As Yves notes, the current rule is also consistent with classic<br>
encoding (and VRML). Right now, my MFString handling in view3dscene is<br>
just firing up a VRML lexer to interpret the MFString attribute<br>
contents. With your change, we either also change the classic<br>
encoding, or we need a little different code to handle MFString in XML<br>
encoding.<br>
<br>
Neither 1. or 2. are a large disadvantage in my eyes, so I'm not<br>
refusing this change. I'm only saying that it's a little more<br>
intrusive change than the simpler plan to "just fix the specification<br>
to allow what XML allows".<br>
<br></blockquote><div><br></div><div>Completely agreed and maybe the change would be too intrusive.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> Backslash escaping for printing is required in any case.<br>
><br>
> I don't understand that part.<br>
<br></blockquote><div><br></div><div>I apologize for the very abbreviated statement. Thanks, Michalis, for explaining this much better.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If I may, I think I can explain what Andres meant:<br>
<br>
You must already use double backslashes to get a single visible<br>
backslash in MFString. After the Andreas proposed change, you would<br>
need to protect single-quotes (apostrophes) by backslashes, but that's<br>
not a problem (it does not cause an incompatibility for correct X3D<br>
scenes), because all the backslashes in current X3D scenes are either<br>
doubled (to mean a single backslash) or they are used to protect the<br>
following character.<br>
<br>
Consider this example:<br>
<br>
<Text string=""here is \'text surrounded in apostrophes\'"" /><br>
<br>
Right now it's either incorrect (if you don't think that backslash<br>
before apostrophe is valid) or correct (and no backslashes will be<br>
visible).<br>
<br>
After the proposed Andreas change, this example will always be correct<br>
(and no backslashes will be visible), since then the apostrophes will<br>
need to be (in some situations) protected. So, no compatibility was<br>
broken.<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>