To be easy to parse, we'd probably then want to say that isA needed to come
before any other fields. A parser would have trouble with:
ExtendedMaterial { fields [ MFString isA ]
diffuseColor .8 .54 .1
isA "Material"
}
... since it wouldn't know that ExtendedMaterial was a material until it had
parsed the diffuseColor field. That makes isA a little bit special, which
makes me a little bit uncomfortable (yes, the fields[] specification must
also come first, but it isn't a "real" field).
Not re-stating the fields repeatedly would save some bandwidth. However, I
claim that the bandwidth savings won't be significant, for two reasons:
-- a well-structured VRML file with well-designed extended objects will be
over 90% raw data (vertex coordinates, lists of colors, ...), with a little
extra overhead for supporting syntax. Re-stating fields is in that small
percentage of supporting syntax.
-- extended nodes will be fairly uncommon
If we really want to squeeze bandwith, it probably makes more sense to
require the fields[] description only for the first occurence of a new node
type in a file. So if you had 1,000 ExtendedMaterial nodes only the first
would need the fields[] string; parsers would have to remember that they'd
already seen the ExtendedMaterial description. Maybe in VRML 1.1 if we find
that the fields[] overhead is significant?