Huh? VRML implementations should feel free to use whatever internal
representation for numbers is most efficient. If I were writing a VRML
viewer for a PC I'd figure out how to convert from VRML's arbitrary floating
point into a fixed-precision representation (probably by measuring the
bounding boxes of the leaf objects and choosing an appopriate scale if they
didn't match the dynamic range of my chosen fixed-point representation).
Transmitting fixed-point, 16-bit numbers across the network probably also
makes sense. But perhaps a separate format isn't necessary-- we could add a
FixedPointCoordinate3 { point 990 FE4A1235BBB800980076543...etc } that
encoded the points in some binary format transliterated into ASCII (I'm
inventing a new field on the fly here-- the 990 would be the count of number
of bytes to follow, with the bytes just hex values jammed together).
Combined with compression that should be almost as efficient as a binary
format (gzip will pretty quickly figure out how to represent any 4 hex digits
using a little more than 16 bits, and will be just a little less efficient
than a binary format which would, of course, do it in the minimal 16 bits).
Tokenizing, in my opinion, won't be a big enough win to justify the effort.
Ask yourself this: would tokenizing HTML be worth it? If not, why not?
Why is VRML different? I think the answers are "No", "because HTML files
are each pretty small (e.g. books are divided into chapters with links)", and
"because VRML's 'alphabet'-- descriptions of polygons-- takes a lot more
room".
I don't buy Mark's argument that tokenizing WWWInline/LOD heavy worlds will
save a lot of space. The problem won't be with the structuring files; the
problem will be with the leaf nodes that actually describe all the geometry
and are full of numbers. I can describe the entire world with:
Separator {
WWWInline { name "PacificOcean.wrl" }
WWWInline { name "Europe.wrl" }
WWWInline { name "Africa.wrl" }
... etc, maybe 30 more WWWInlines.
}
Sure, those files will, in turn, be composed of lots of WWWInlines. Until
you start describing the actual geometry of the continents the .wrl files
will be so small even simple gzip compression won't matter much.
We shouldn't spend time optimizing for things that aren't a problem.