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

Yves Piguet yves.piguet at gmail.com
Thu Mar 16 03:39:33 PDT 2017


> On 16 Mar 2017, at 10:59, Don Brutzman <brutzman at nps.edu> wrote:
> 
> 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.

I suggest to modify the wording, not the meaning.

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

Please see my spec comment 1108 which I sent to x3d-public yesterday in my first reply to Andreas.

>>> 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.

I mentioned canonical forms related to the xml, and possibly json, encodings. I think 19776-3 is about the compressed binary encoding, which I haven't studied at all. 19776-3 4.2.3 seems to define a canonical xml encoding, which I'm surprised to find there if it's supposed to have any significance outside the scope of compressed binary.

>> 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.

If you must explain in details exactly what is interpreted how, which characters must be escaped where, a simple rule might win.

Are there really many authors who write XML by hand? Many X3D examples use the classic encoding. Imo, XML isn't user-friendly anyway.

> 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.

Many parsers will try to stick to the standard, I hope.

Thanks,

Yves




More information about the x3d-public mailing list