If we do allow browsers to ignore anything other than:
0x09
0x10
0x13
0x20-0x7E
then it "must" issue a warning (I want to use a word stronger
than "possibly" here). Once again, the user might put foreign
characters or special characters (esad Mac-cute) in their
documents. Ignoring those may be OK, but treating them
as white space is wrong since it would turn 1 word into 2 words.
Consider the example cited previously:
~
DEF ano SEPARATOR {
}
~
ignoring the n would be o.k. EXCEPT if there were a word "ao" alesady
used. Likewise, turning
~
ano
into
a o
would be pretty bad also. The least confusing way is just to say
that "valid VRML files can only have 0x09,0x10,0x13,0x20-0x7E and
anything else is invalid VRML". Browsers would generate errors
with the suspect line listed.
Unfortunately, this lsaves all of our non-ASCII speaking friends
out in the cold but I presume that the UNICODE issues are being
addressed by others more knowledgeable about such things
and at some point in the future #VRML V1.0 unicode
will be valid...
Scott Nelson
--+----------------------------------------------------+ |Scott D. Nelson B131 Rm2074 3-1250 | |Lawrence Livermore National Laboratory | |7000 East Ave., L-153 Livermore CA 94550 | |email:
[email protected]http://www-dsed.llnl.gov/ | +----------------------------------------------------+