[x3d-public] Mantis 1320: relax requirement for quoted single-string value in MFString array

[Don Brutzman]

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.

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.

For example, pseudocode adaptable to ~any language that is parsing text into X3D objects:

	if (!value.startsWith('"') and !value.endsWith('"')) // example approach #1
	{
		newMFStringValue = new MFString() of length 1;
		newMFStringValue[0] = value;
	}
	else // continue parsing as before

Even simpler test condition:

	if (!value.contains('"')) // example approach #2

Sample tests for each respective approach above:

	<Text string="hello world"/>        <!-- allowed by example approach #1 and #2 -->
	<Text string='hello world'/>        <!-- identical result -->

	<Text string='we \"love\" you Ma!'/><!-- allowed by example approach #1 but #2 is too simple -->

I have a variety of utility methods in XSLT, Java, Python, other Java, etc. that accomplishes this without difficulty.  Given some care regarding where this goes inside a parser, the test itself is simple.

Performing regression testing on lots of diverse X3D content has helped me see a broader balance here.  It is important for all of us to recognize that avoiding errors (in both authored and autogenerated content) is quite valuable to everyone: users, authors, tools, converters, and browser implementers.

This relaxation is unambiguous and leads to more robust X3D content as well as more reliable/readable metadata sets.  Am not trying to shortcut quality, rather am trying to support more robust quality that gets widely used.

Incidentally, regardless of whether/when the X3D XML Encoding gets improved, I recommend all X3D parsers implement this approach in your implementation.  Happy users don't need to send "bug" reports for content that makes sense but fails for arcane reasons.

Further rationale:

* Robustness principle (aka Postel's Law)
   https://en.wikipedia.org/wiki/Robustness_principle

   "Be conservative in what you send, be liberal in what you accept"

Not a goal: disambiguating trivial or complex or erroneous strings that contains embedded quotation marks.  The regular MFString quoted-string rules are suitable for all potential combinations.

Worth considering: most non-X3D programmers (umm, a whole lot of people around the world) will not bother with carefully nested single/double/escaped quoting, will avoid such problematic content, and will likely consider such a language requirement as broken.

Hope this helps explain better.

Also good to remember that the group goal for technical consensus is NOT (a) we all agree symmetrically on every single technical tradeoff, but rather (b) everyone implementing code or content says "I can live with that."

If you have any simple requirements or examples that get thwarted by this MFString-singleton relaxation, please share and explain further.  Am unaware of any counterexamples.

Thanks for considering this enhancement Michalis.


On 7/4/2020 3:11 PM, Michalis Kamburelis wrote:
> 
> This was discussed in the past, as far as I remember. I don't think it's a good idea to add the proposed exception to the spec (to treat MFString content, without additional quotes inside, as valid, and just treat it as a single string).
> 
> MFString is encoded differently than SFString in XML encoding. Tools and authors should be aware of it. (And we should explain it precisely in the spec.)
> 
> - In MFString, you have to surround each part by additional quotes,
> - The backslashes interpretation is different in MFString ("backslashes are NOT used for escaping inside SFString", but they are used in MFString).
> 
> Adding a special rule, to allow to treat such (currently incorrect) MFString content as valid, would add to the confusion IMHO. It is already confusing because  we have not applied, as far as I know, the spec clarification that we wrote on a few years ago -- it is on https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding . But at least that proposed clarification is consistent right now with what existing browsers are doing.
> 
> Regards,
> Michalis
> 
> sob., 4 lip 2020 o 22:57 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> napisał(a):
> 
>     * Mantis 1320: relax requirement for quoted single-string value in MFString array
>     https://www.web3d.org/member-only/mantis/view.php?id=1320
>         Specification: 19776-1 (X3D XML Encoding)
> 
>     A superfluous, confusing and error prone requirement in XML Encoding is to always require quotation marks around every string value, including when using a singleton string as part of an MFString array.
> 
>     This requirement can be relaxed without ambiguity, provides reduced difficulty for converters and parsers, and has no backwards-compatibility issues for model content. Relaxing this requirement also makes MFString more compatible with SFString.
> 
>     Suggested specification prose addition:
> 
>     * "Unquoted MFString values are treated as a singleton SFString value."
> 
>     Corresponding prose removal:
>     ================
>     NOTE The construct "string3" is not a valid instance of an MFString. Such an MFString would be properly specified as '"string3"'
>     ================
> 
>     TODO need to check other encodings and language bindings to ensure this relaxation is similarly applied.
> 
>     Specification reference:
> 
>     * X3D XML encoding, 5 Encoding of fields, 5.15 SFString and MFString
>     https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString
> 
>     [This long-standing issue may have a prior Mantis entry, but I was not able to find it.  Cross-reference issues welcome.]

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman