[x3d-public] MFString quotes; X3D XML canonical form; unquoted MFString value can be rendered if player chooses

[Don Brutzman]

On 3/15/2017 8:08 AM, Yves Piguet wrote:
>> On 15 Mar 2017, at 15:35, Don Brutzman <brutzman at nps.edu> wrote:
>>
>> Short summary:
>>
>> a. The abstract specification is unambiguous.
>
> Imo, XML applications like the XML encoding of X3D shouldn't restrict XML, or they shouldn't claim to be XML. So 19776-1 should be modified.

Not clear to me what should be modified, it seems to work.

If there are specific improvements in phrasing or clarity that can be achieved, then great.  All suggestions welcome.

>> b. Different file and language encodings have similar yet different rules about escaping quotes.
>> c. We have no control over external equivalences, since user agents decide independently (e.g. " and ")
>
> I agree.

So far so great.

Not yet mentioned in this email thread, of related interest:

X3D Canonical Form defines how a file can best represent content consistently.  This is not only helpful for diffing and version control, but also for consistent use of XML digital signature or XML encryption.

	4.2.3 X3D canonical form
	http://www.web3d.org/documents/specifications/19776-3/V3.1/Part03/concepts.html#X3DCanonicalForm

We needed this definition because some of the XML Canonical Form defaults were not optimal for X3D.

YMMV (eye of the beholder) but seems like most readable form as well.

>> d. Round-tripping is difficult/tedious but possible in every case.  Repeatable code blocks can help.
>
> Usually possible for a given implementation. If you think round-tripping is useful, one should refer to a canonical XML representation. See https://www.w3.org/TR/xml-c14n
>
> Same for JSON. Same for Classic (standardized pretty-printed?)

Yes, wondering if that is defined somewhere?

Once next JSON v5 schema specification is stabilized and we apply it to X3D, that will be a good time to look at corresponding JSON security and JSON canonical form and JSON minifier issues.

>> I think one relaxation might be possible where an unquoted MFString value might be treated as a single SFString value in the array.
>
> I'd rather not. The more permissive, the more difficult it will be to fix design oversights later if there are. XML isn't nice to write by hand anyway, one shouldn't try to accept sloppy code.
>
> For instance, in XML all attribute values must be quoted, unlike HTML. Being lenient here would go against this design choice.

Yes that is the conservative approach and that argument has won the day in the past.  Even so...

I acknowledge the point in theory, but just have never seen anything difficult in practice.  Frankly since a single statement can address the issue, e.g. here is some pseudocode:

	// wrap quotation marks for singleton MFString
	if (!someValue.contains("\"")
	     someValue = "\"" + somevalue + "\"";

Thus the burden on implementers parsing an X3D scene is trivial.  However the burden on authors and end users (both are much much larger populations) is significant when the following common (mistaken) construct breaks a scene:

	<Text string="crash this scene, ouch"/>

Of further note is that a warning can be thrown, and lint/validator/tidy tools can still detect it, but the scene renders OK with no other side effects.

Also of note, this is the kind of design idiosyncracy that makes people think a language is difficult inscrutable and unreliable.  Do we really want to tell new adopters "gosh so sorry you lost an hour/day/week of production time, to be legal your otherwise-perfect X3D scene should use the following incantation"

	<Text string='"do not crash this scene, bwahaha"'/>

Unnecessary pain.  Much better is when simple things work, then the author later learns to add quotation marks for multiple strings in an MFString array.

Thus it still seems preferable overall (meaning for everyone's benefit) that the XML encoding of the X3D specification to allow this special case for singleton MFString values.

Meanwhile, mercifully, players can also choose to accept it (X3D never requires a specific error response).  So your X3D parser doesn't have to fail on that obvious construct. Your choice.

um, dear implementers, *please steal and adapt and apply that statement* to be forgiving about unquoted MFString values.

> Best,
>
> Yves

merci Yves

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