[x3d-public] agreement on number of \\\\\\\\ in Java???? X3DJSAIL.

[Don Brutzman]

Let's think about how we might handle "different" SFString content.  If we get base case consistent and correct, then adapting such an SFString value when loading it in an MFString array is possible.

Saving grace (and necessary checkpoints) throughout will be first considering the in-memory on-screen value, then considering the corresponding escaping in each encoding & language binding.


On 7/29/2017 9:27 PM, Michalis Kamburelis wrote:
> 2017-07-29 22:23 GMT+02:00 Don Brutzman <brutzman at nps.edu>:
>> Observation: it is quite important that MFString and SFString get
>> represented consistently.  Author clarity and usage needs to be correct (of
>> course).  Programmatic consistency is also necessary since SFString value(s)
>> may be typecast or composed into an MFString value.
> 
> Consistency is an important design criteria, I absolutely agree. But
> in the case of backslashes in X3D XML it's too late to make them
> consistent now. That was the point of my message "Backslashes in X3D
> XMLin SFString" to x3d-public on 2017-05-11,
> http://web3d.org/pipermail/x3d-public_web3d.org/2017-May/006690.html .
> 
> - All the existing browsers (including my own) treat backslashes as a
> special escape character in X3D XML MFString,
> - and no browser treats backslash as anything special in X3D XML SFString.
> 
> So the implementations have already converged on a consensus, even
> when the specification is imperfect. This behavior makes sense if you
> consider a typical X3D XML implementation: in case of MFString you
> need to parse the contents to split it, while in case of SFString you
> just take the value of XML attribute. So it's completely natural  to
> *not* treat backslash as "special" in case of X3D XML SFString.
> 
> And authors and conversion tools have already learned to cope with
> this, as far as I know. So changing it now (or in X3D 4.0) would be
> counter-productive, I think. Instead, the specification wording should
> be adjusted to make it clear how (all) browsers behave. That's the
> underlying theme in my corrections.txt, they not only make the
> specification more correct / more precise, they also mostly describe
> how existing browsers actually work already :)
> 
> Regards,
> Michalis
> 


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