[x3d-public] MFString quotes

[Leonard Daly]

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>