Yes, in ASCII the '{' isn't really necessary.
Inventor's binary format has neither the '{' nor the '}'. Inventor's binary
parser always knows exactly how many bytes need to be read.
> >And we should bear expansion in mind. Extension nodes will (by
> >definition) not be part of the standard, so they won't have
> >predefined tokens. We should chew on how to handle them. We
> >could run them in full ASCII, or have some kind of prelude that
> >defines (for the duration of the file) the token for that
> >keyword, or maybe something else. There are numerous ways we
> >could deal, but we will need to choose one.
>
> Perhaps we should have a "DEF range" of tokens that can be dynamically
> allocated by the VRML binary-izer. Then we can explore "reference by
token"
> options.
Extensions are probably rare enough that they should just be represented in
ASCII. Now is probably a good time to start thinking about
internationalization, though-- in the Inventor group, we're contemplating
changing from a pure 7-bit ASCII format to a UTF8-based 8-bit format. And
we'll probably allow node type names, DEF/USE names, string fields--
EVERYTHING-- to be UTF8.
BUT:
I'm still unconvinced that a binary format for VRML is necessary. Certainly
John Foust's experiments reconfirm what we've found-- compressed ASCII tends
to be as small as binary. If the bottleneck is file transmission speed (and
not the time it takes to parse the input), compression works just as well as
a binary format. And supporting compression is a whole lot easier than
supporting a binary format, since the code for gzip is already freely
available.
I think that adding some more efficient primitives (e.g. ElevationGrid,
IndexedTriangleStripSet and QuadMesh), when combined with already-existing
compression, will give us more bang for our design buck than coming up with
tokenization schemes or fixed-point number representations.
And I don't think any of these will be good enough. We need good tools to
automatically create low levels of detail and smart browsers that know not to
pull across huge files (= the higher levels of detail) unless the user says
that they are willing to wait.
Footnote:
I was curious to see how much tokenizing could possibly improve on of my
favorite models. To get an idea of how many characters were dedicated to
Separator {, fieldName [ ... etc, I did:
ivcat /usr/share/data/models/buildings/Barcelona.iv | grep '[a-zA-Z]' | wc -c
... and got 346 characters, out of a total of 542,302 characters. Or .06
percent. Well-structured VRML files should be similar, with lots and lots of
numbers and very little format overhead.
And just limiting your ASCII numbers to a couple of digits after the decimal
point and then compressing should make them just as small as fixed-point
numbers...