<div dir="ltr"><div>Don,</div><div><br></div><div>About your implementation and samples, there are 2 errors. Which shows my point -- this issue has complicated details :)<br></div><div><br></div><div>1.You need to account that the character may also be " (literal double quote), they don't need to be expressed using HTML entities when you surround the XML attribute using apostrophes. (One point of our proposed text, on <a href="https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding">https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding</a> , was to clarify this).</div><div><br></div><div>2. Your example <Text string='we \"love\" you Ma!'/> does not work like you probably think. Since now this is treated like an SFString, the backslashes are *not* special, and so they would be visible. Please see my discussion of backslashes on the bottom of <a href="https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding">https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding</a> . This was discussed on this mailing list, with a consensus, and my description there matches what browsers are already doing.<br></div><div><br></div><div>And there remains a problem Vince noted: what is an empty string now? Previously it was MFString with 0 items. Now it will be MFString with 1 item equal to an empty string. This difference matters in some edge cases e.g. "Text" node will have a different size now, as it has 1 row.</div><div><br></div><div>In general, the rationale """be liberal in what you accept""" is not convincing IMHO. That is not what a usual programming language is doing. You don't want to liberally accept everything that may make sense -- because this leads to a language with lots of special rules and allowances, which leads to a language that is hard to understand / predict. Instead, the usual guideline is that language should apply the rules consistently.</div><div><br></div><div>My practical problem is that this new rule would create a confusion for authors. Your own example shows this, as you were confused with how <Text string='we \"love\" you Ma!'/> works.</div><div><br></div><div>I imagine these scenarios:<br></div><div><br></div><div>1. I start with a <Text string="bla bla" /> . Cool, it just works. <br></div><div> <br></div><div> - But now I want to add a second line. So I need to learn to surround the first line in double quotes now anyway: <Text string=""bla bla" "another line"" />.</div><div><br></div><div>2. I start with a <Text string='we "love" you Ma!' />. Cool, it just works. <br></div><div><br></div><div> - But now I want to add a second line. So I need to learn to surround the first line in double quotes now anyway: <Text string='"we "love" you Ma!" "another line"' /></div><div><br></div><div> - And now I need to learn about backslashes, because the above example will fail. Both " and " inside delimit string parts, so I actually need <Text string='"we \"love\" you Ma!" "another line"' /></div><div><br></div><div>These cases show how an author would get confused. Having to do the correct thing (with quotes and backslashes) at the beginning, means that you have a harder start (you need to understand these quotes and backslashes), but then you have a smooth way ahead, because it's obvious how to add a 2nd string.<br></div><div><br></div><div>And existing tools (both writing and reading) have learned to cope with this throughout the years. I doubt that these additional quotes are a blocker for X3D adoption -- it's trivial to explain them, "they are there because you may have multiple strings, and we have a general way of writing many strings inside one XML attribute".<br></div><div><br></div><div>All in all, I'm still not convinced.</div><div><br></div><div>Regards,</div><div>Michalis<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">niedz., 5 lip 2020 o 05:01 <a href="mailto:vmarchetti@kshell.com">vmarchetti@kshell.com</a> <<a href="mailto:vmarchetti@kshell.com">vmarchetti@kshell.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Apologies, this fragment of a reply was sent prematurely and is incomplete, ignore it for now.<br>
<br>
Vince<br>
<br>
<br>
> On Jul 4, 2020, at 10:58 PM, <a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a> wrote:<br>
> <br>
> <br>
> <br>
>> On Jul 4, 2020, at 9:26 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>> <br>
>> Thanks for your note... yes we had a brief discussion some months ago, will look it up. Didn't want to dwell on the topic then (each of us too busy!!) but now more metadata is getting created and this relaxation will help.<br>
>> <br>
>> My understanding of years of implementation-complexity objections heard to this XML encoding relaxation have not appeared to be grounded by practice, which in this case is quite simple.<br>
>> <br>
>> For example, pseudocode adaptable to ~any language that is parsing text into X3D objects:<br>
>> <br>
>> if (!value.startsWith('"') and !value.endsWith('"')) // example approach #1<br>
>> {<br>
>> newMFStringValue = new MFString() of length 1;<br>
>> newMFStringValue[0] = value;<br>
>> }<br>
>> else // continue parsing as before<br>
>> <br>
>> <br>
> <br>
> However, I think this approach of coming up with code or pseudo code to explain or document the standard doesn't account that implementors will want to (and I think should) use standardized code to do all the XML processing, including applying the XML rules for un-encoding the way that attribute values can be encoded in XML.<br>
> For example, given an XML fragment<br>
> <Element fruit='"apple"'/><br>
> <br>
> However, the same could be <br>
> <br>
> <br>
> <br>
> Someone using the standard Python module xml.etree to parse the document would only see a Python object with a (Python) attribute named fruit and a value which was the unicode value "apple" . If this occurred in an X3D document,<br>
> this would be interpreted as an SFString with value "apple" or an MFString of one element with value apple . <br>
> <br>
> <br>
> <br>
> <br>
> <br>
>> all the best, Don<br>
>> -- <br>
>> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
>> <br>
>> _______________________________________________<br>
>> x3d-public mailing list<br>
>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> <br>
> <br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>