[x3d-public] singleton MFString values (unquoted string)

[Don Brutzman]

Thanks Vince and Michalis for all of the careful thought on MFString parsing.

Apologies for not responding inline to prior email thread (our NPS email filters are still applying security-motivated link redirection to all url values that really obscures things, am working to relax that). Will try excerpts.

This and prior threads:

[1]	

On 3/17/2021 2:36 PM, vmarchetti at kshell.com wrote:
> 
> The proposal is to relax the prohibition as described, but I think it would be useful to look at this in another way: A proposal to relax the requirements on a content author is equivalent to adding a requirement on X3D file parsers.

Typically yes, the burden goes somewhere.

In general it seems most efficient to strive for effective and consistent parsing, insofar as possible, across all file encodings and language bindings.

In general, when we make it hard for authors or for tool output, we still increase the load on parsers (which fail and get bug reports).  Plus we reduce the reliability of X3D, at least from the perspective of authors and users who rightfully perceive "hey my X3D model doesn't work - and fails mysteriously too, all I get is a cryptic error message about content that seems to say what I want."

So clarity, consistency, effectiveness, and getting X3D parsing accomplished consistently seems like our shared goal.

> In this case, I think the additional requirement on X3D XML encoding parsers/readers is something like:
> 
> When reading an MFString value, and the 'normalized value' of the attribute is non-empty, and does not begin and end with quote characters, then the parser is required to parse that value as a single SFString value, and treat the X3D field value as an MFString with one contained SFString.

Yes.

> We can see that this is a non-trivial requirement to express, and I am not convinced that even this has the desired effect.

Seems pretty trivial to parse correct content.  Since XML allows either apostrophe or quote mark as an attribute delimiter, the following produce exactly equivalent XML results:

	<MetadataString name='test' value='Hello' /><!-- apostrophe delimiters -->
	<MetadataString name='test' value="Hello" /><!-- quote mark delimiters -->

Given any MFString parser, the following example code can handle special cases.  Here the trim() function removes initial and trailing whitespace.

	if ((value == null) || value.trim()isEmpty()) // no value?
	   newMFStringValue = new MFString();         // empty array

	else if (not(value.contains("\"")))           // are no quote marks found?
	   newMFStringValue = new MFString(value);    // singleton array

	// rest of parser follows

Seems straightforward for parsing syntactically unambiguous content.

> I also argue that it will be necessary to clarify the specification on the backslash issue to properly make the change this proposal suggests.

OK clarity is always good and best judges are the people reading it, not necessarily the people writing it.

Of note: we are first trying to explain the [ "quoted" "string values" ] specified in VRML, and second trying to account for all of the variations inherent in XML itself.

Rephrase: no invention intended, simply striving for complete equivalence of expressive power in XML.

I suspect that once XML is parsed, for example into DOM strings, then the same parsing logic used for VRML might also be applied to those string values.

> We will need to give unambiguous answers to how to address these edge cases :
> 
> <MetadataString name='test' value='"Hello' />

This is a malformed value since it has mismatched outer quote marks.  It should also fail in VRML syntax.

> <MetadataString name='test' value='\"Hello"' />

This is a malformed value since it begins with an explicit character, and has mismatched outer quote marks.  It should also fail in VRML syntax.

> <MetadataString name='test' value='"\"Hello"' />

This should pass.  Resulting single-element MFString will contain value >>>>"Hello<<<<

> <MetadataString name='test' value='"Hello"  ' />

This should pass.  Resulting single-element MFString will contain value >>>>Hello<<<<

and would also be equivalent to either of these:

	<MetadataString name='test' value='Hello' />
	<MetadataString name='test' value="Hello" />

Note that the apostrophes hold the full MFString value, and the quote marks are actual delimiters, so some trailing whitespace after "Hello" is dropped before final apostrophe.

On 3/17/2021 2:38 PM, Michalis Kamburelis wrote:
> 
> Don,
> 
> As I understand, the proposed change here would say "if there are no
> double-quotes (expressed in any way) at the beginning and end of
> MFString attribute content, then parse it as a SFString (since
> otherwise it would be just invalid MFString)".
> [...]

Next: I mostly agree with with what you've said Michalis.

As above, note that the necessary complications are to account for XML syntax, and once XML is parsed, the string values can typically be handled the same.

> I do not think comparing it with classic VRML syntax is valid. In the
> classic VRML syntax, the rules are more consistent for SFString and
> MFString parsing. For better or worse, SFString and MFString parsing
> is already more different in X3D XML syntax, it has to be.

My point is that VRML syntax does not require the outer [ "square brackets" ] on a singleton SFString making up a one-element MFString array.

> That being said, it's not a "strong disagreement". If such rule would
> be clearly explained in the spec (in particular explaining what it
> means for backslashes) I can "live with it" :)

Thanks.  I think we are all looking for something we can live with!

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