[x3d-public] MFString quotes
Leonard Daly
Leonard.Daly at realism.com
Wed Mar 15 13:49:03 PDT 2017
It seems to me that there is some confusion, though I am not sure if the
confused is me or others. Certainly I made a mistake that Patrick Dahne
caught and commented on (thanks).
For X3D all string elements must be quoted. This is true in any
text-based encoding.
Using the field 'string' of the 'Text' node as an example defining a
2-element MFString field. For Classic VRML it is
string ["string 1" "string 2"]
in the XML encoding the elements still need to be quoted. XML (as many
have noted) also requires that all attribute values be quoted, though it
does not care if a single or double quote is used. So both of the
following are legal:
<Text string='"string 1" "string 2"'/>
<Text string=""string 1" "string 2""/>
Note that the XML element produces an MFString with 1 element
<Text string="'string 1' 'string 2'"/>
In this case the single element would be - 'string 1' 'string 2'
Finally, my comment about turning individual elements into children
applied to all MFString fields. I don't think there is the same value
for MFColor, MFVec3f, etc. It certainly does not apply to S* data types
(e.g., SFVec3f). So the translation field of Transform would remain as
SFVec3f and be represented as a 3-tuple of floating-point numbers.
Leonard Daly
>> For instance, in XML all attribute values must be quoted, unlike HTML
>
> Yeah, so XML can be hard for X3D MFStrings. When web3d started with
> X3D XML, XML didn't really know about any MF fields. MFString
> equivalents are complicated when user wants legal html double and
> single quotes and apostrophies in the displayed text.
>
> X3D cannot allow the html legacy unquoted MFString and still function
> as expected. So that is only the first of the reasons why X3D must
> stick as close as possible to XML and XHTML rules and not allow the
> the legacy htmlized unquoted string in any <x3d > ... </x3d> syntax.
> Leonard has pointed to the most simple solution for simple encodings
> that don't allow mulitple data strings like x3d uses for urls and
> other MFString fields listing multiple strings that use coombinations
> of htmllegal single or multiple quotes to enclose the MFString and
> separate the individual SFStrings, and also character entities and
> escaping.
>
> So, for these string cases, like Leonard suggests, maybe allow an
> optional construction that doesn't use MFString form and, if it is an
> X3D MFString, then allow listing each or the the strings individually
> as elements? However I might fear that is only a slippery slope to
> allowing other MFfields (like translation, for instance) to be broken
> up and maybe even end up with ultimate ridiculous simplications that
> lose strong type checking (like translation becoming a wrapper for
> individual x y z element content).
>
> Thanks and Best,
> Joe
>
>
>
> ----- Original Message ----- From: "Yves Piguet" <yves.piguet at gmail.com>
> To: "Don Brutzman" <brutzman at nps.edu>
> Cc: "Andreas Plesch" <andreasplesch at gmail.com>; "X3D Graphics public
> mailing list" <x3d-public at web3d.org>; "Leonard Daly"
> <Leonard.Daly at realism.com>
> Sent: Wednesday, March 15, 2017 8:08 AM
> Subject: Re: [x3d-public] MFString quotes
>
>
>>> 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.
>>
>>> 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.
>>
>>> 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?)
>>
>>> 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.
>>
>> Best,
>>
>> Yves
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170315/4b4031a8/attachment.html>
More information about the x3d-public
mailing list