[x3d-public] question on MFStrings; intermediate whitespace between SFString values in MFString list?
Joe D Williams
joedwil at earthlink.net
Sat May 20 14:59:25 PDT 2017
Yes, a space is good but a comma must also work. And in this case of
MFs multiple SF quoted strings there is just no reason to reject the
input due to space missing between quoted strings, just sayin' IF you
format the stufff, thenyou may certainly choose to add a space or
comma. Again, for all other MFs, each SF needs a spae or comma and
SGstrings in MFstrings are eally a unique special cas due to the
bounding quotes.
Despite this minor detail the MFstring may still be (one of) the
easiest of all to regex. Just find if the SFs are bounded right, then
it is just legal characters and entities and escaped characters and
entities. I caught something about newlines but newlines as a part an
SF, or anywhere else should not be honored. text generates the newline
for each SF.
Thanks
Joe
,
----- Original Message -----
From: "Don Brutzman" <brutzman at nps.edu>
To: "Joe D Williams" <joedwil at earthlink.net>; "John Carlson"
<yottzumm at gmail.com>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Saturday, May 20, 2017 12:27 PM
Subject: Re: [x3d-public] question on MFStrings; intermediate
whitespace between SFString values in MFString list?
> On 5/20/2017 7:41 AM, Joe D Williams wrote:
>> please keep it simple and allow the only exception to the MF rule
>> of space or comma between SF elements of MF fields. Of course
>> numerical MF must no exceptions, but
>>
>> string='"a""b"'
>> string='"a" "b"'
>> string='"a","b"'
>> all are good.
>>
>> No reason for MFstring to not allow zero spaces or in fact any
>> number of combinations of spaces and no more than one comma.
>
> Hi Joe. Am expecting that there must be whitespace between SFString
> values in an MFString array, but let's check.
>
> If omitted, X3D Schematron will squawk:
>
> <Text DEF='' string='"Target Locked" " FIRE!..""(Green
> Button)"'/> string array has questionable line-break "" quote marks
> [/X3D/Scene/Transform[1]/Transform[7]/Transform[6]/Shape/Text,
> error]
>
> XML DTD doesn't have sufficient expressive power to detect this
> issue.
>
> XML Schema doesn't currently detect this issue, but might someday if
> someone comes up with an MFString regex.
>
> Getting more rigorous:
>
> ============================================
> X3D XML Encoding, 5.15 SFString and MFString
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFString
>
> The SFString and MFString fields contain strings formatted with the
> UTF-8 universal character set (see ISO/IEC 10646-1). SFString
> specifies a single string encoded as a sequence of UTF-8 octets
> enclosed in double quotes (e.g., "string"). The MFString specifies
> zero or more SFStrings enclosed in single quotes (e.g., '"string1"
> "string2"').
> [...]
> ============================================
>
> Whoa. Not seeing a requirement for whitespace between successive
> SFString values. We should be explicit about that, one way or the
> other, so you have identified a specification ambiguity. 8)
>
> Looking further:
>
> ============================================
> X3D ClassicVRML Encoding,5.15 SFString and MFString
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFString
>
> "The SFString and MFString fields contain strings formatted with the
> UTF-8 universal character set (see ISO 10646). SFString specifies a
> single string. The MFString specifies zero or more strings. Strings
> are encoded as a sequence of UTF-8 octets enclosed in double quotes
> (e.g., "string")."
> [...]
> ============================================
>
> Once again, not seeing a requirement for whitespace between
> successive SFString values. Another specification ambiguity.
>
> Checking the grammar:
>
> ============================================
> X3D ClassicVRML Encoding, Annex A (normative) Grammar, A.1.2
> Overview
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Overview
> [...]
> The carriage return (0x0d), linefeed (0x0a), space (0x20), tab
> (0x09), and comma (0x2c) characters are whitespace characters
> wherever they appear outside of quoted SFString or MFString fields.
> Any number of whitespace characters and comments may be used to
> separate the syntactic entities of an X3D file.
> ============================================
> X3D ClassicVRML Encoding, Annex A (normative) Grammar, A.4 Fields
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Fields
>
> mfstringValue ::=
> sfstringValue |
> [ ] |
> [ sfstringValues ] ;
> ============================================
>
> Since zero is a number, "Any number" could strictly mean no
> whitespace.
>
> Now looking at X3D Abstract Specification, 5.3.14 SFString and
> MFString
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.html#SFStringAndMFString
>
> ... as expected, no encoding rules regarding whitespace between
> array values found there.
>
> So, what do we do?
>
> It is valuable for parsers be able to consistently read MFString
> payloads for each payload, if possible, for consistency and quality
> control.
>
> From a parser-implementation perspective, expecting or allowing
> whitespace following each SFString value in an array seems quite
> similar.
>
> We should also confirm that other MF array times are consistent
> about whitespace; on first inspection they seem OK, and it is hard
> to imagine an array being definable without whitespaces separators.
> Still will be good to recheck prose.
>
> Wondering what current practice in X3D players might be? Is
> whitespace required between SFString values in an MFString list?
>
> Let's see. If we use X3D-Edit to autolaunch multiple players using
> HelloWorld.x3d with no interior whitespace,
>
> <Text DEF='TextMessage' string='"Hello""world!"'>
>
> works: Cobweb, X3DOM, freeWrl, H3Dviewer, InstantReality,
> view3dscene, Xj3D, BSContact
> fails: none
> inconclusive: Octaga VS (seems to fail either way, might be my
> current setup)
>
> Being forgiving about intermediate whitespace is certainly preferred
> from a "let my content play!" perspective. 8)
>
> Absent objections or further observations, it looks like we should
> submit a specification feedback, enter a Mantis issue, and make the
> X3D ClassicVRML and XML encoding specifications explicit about this.
>
> p.s. The X3D JSON encoding seems unambiguous about separating
> values, e.g.
>
> { "Text":
> {
> "@DEF":"TextMessage",
> "@string":["Hello","world!"],
> "-fontStyle":
> { "FontStyle":
> {
> "@justify":["MIDDLE","MIDDLE"]
> }
> }
> }
> },
>
> On 5/20/2017 7:41 AM, Joe D Williams wrote:
>> [...] and no more than one comma.
>
> Interesting insight. In ClassicVRML any intermediate comma is
> treated as whitespace, so we can't touch that.
>
> The X3D XML Encoding is already more restrictive in that commas are
> only optionally allowed between tuples, for example between (but not
> within) SFVec3f values within an MFVec3f array.
>
> So only allowing one comma would seem to be in the same spirit,
> which is intended to identify flaws in looong arrays that are
> otherwise ~ impossible to find.
>
> Let's think further about feasibility of that potential tightening.
>
>> I think a properly formatted listing would use the comma to sep the
>> SFs
>> '"a","b"'
>> because that works best for every MF readability
>
> Well X3D Canonical Form requires whitespace between values in an MF
> array, and matches XML Canonical Form which does not permit commas
> as whitespace.
>
> ============================================
> X3D Compressed Binary Encoding (CBE), 4.2.3 X3D canonical form
> http://www.web3d.org/documents/specifications/19776-3/V3.3/Part03/concepts.html#X3DCanonicalForm
>
> a. Whitespace rules:
> 1.Whitespace is defined as carriage-return, line-feed, space, tab,
> and comma characters. Whitespace separates all MF-type array values,
> including individual element values within MFString arrays.
> 2.All whitespace characters are converted to a normalized
> (single-occurrence) blank character with no leading or trailing
> whitespace.
> 3.All literal characters within an SFString value are retained
> verbatim.
> 4.All literal characters within MFString array values are retained
> verbatim.
> ============================================
>
> Just tested X3D Canonicalizer, it is not inserting whitespace. Bug
> to be fixed.
>
> Similarly tested X3D Tidy, which strives to match X3D Canonical
> Form. It is not inserting whitespace. Bug to be fixed.
>
> Thank you Joe for pushing on this corner case. X3D Working Group
> will review and resolve accordingly.
>
>> Thanks,
>> Joe
>>
>>
>> ----- Original Message ----- From: "John Carlson"
>> <yottzumm at gmail.com>
>> To: "Don Brutzman" <brutzman at nps.edu>
>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>> Sent: Friday, May 19, 2017 11:43 AM
>> Subject: Re: [x3d-public] question on MFStrings in XML.
>>
>>
>> I don’t see a space between the second and third SFStrings in the
>> MFString here:
>>
>> https://savage.nps.edu/Savage/AircraftFixedWing/F16-FightingFalcon-Turkey/F16Index.html
>>
>> John
>>
>> Sent from Mail for Windows 10
>>
>> From: John Carlson
>> Sent: Friday, May 19, 2017 2:40 PM
>> To: Don Brutzman
>> Cc: X3D Graphics public mailing list
>> Subject: RE: question on MFStrings in XML.
>>
>> Hmm. Should I download a new zip?
>>
>> Sent from Mail for Windows 10
>>
>> From: Don Brutzman
>> Sent: Friday, May 19, 2017 1:09 PM
>> To: John Carlson
>> Cc: X3D Graphics public mailing list
>> Subject: Re: question on MFStrings in XML.
>>
>> On 5/19/2017 9:06 AM, John Carlson wrote:
>>> I’m not worried about the extra spaces, I’m worried about the
>>> missing space between the 2^nd and 3^rd strings, and how we are
>>> going to handle it in X3dToJson.xslt, compared to ‘“FIRE” “”
>>> “FIRE”’
>>
>> there is a space character (between second and third SFString
>> values) in the source and my reply... perhaps earlier mail got
>> squished? or am i missing something?
>>
>> agreed that whitespace is necessary between SFString values in an
>> MFString array.
>>
>> all the best, Don
>
>
> 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
More information about the x3d-public
mailing list