If a custom node has fields, then the default values for those fields are
known only if the custom node is known (-- if the browser can somehow find
an implementation for the custom node, through a DLL or whatever).
If an implementation can't be found, then the default values for those
fields is not know. Happily, that shouldn't cause any problems, because
the browser can't do anything with the fields of an unknown custom node
anyway.
> And, if the file is 1.0, then the new "nearDistance" and "farDistance"
fields which are 1.0 should be added with a fields[] declaration, right?
I'm a little confused. 'nearDistance' and 'farDistance' are NOT part of
the VRML 1.0 spec. They will be part of VRML 1.1; they can't be added to
VRML 1.0, because only clarifications (not additions or deletions) are
allowed to the 1.0 spec.
> Under "Extensibility":
>
> This is a little bit in contradiction with the section of extensibility
that says "The fields specification must be written out with every
non-standard node, whether or not that node type was previously
encountered during parsing." If so, then all these files (including many
on the test sites) are not VRML compliant and need to be fixed.
Huh? Point me at a URL. I know I sometimes play fast and loose with VRML
syntax when I'm trying to get a point across, and use made-up nodes when I
want to talk about nodes in general (and not Cubes or Spheres or...).
> (Question: is "Foo { fields [] }" legal and required?)
Yes, legal and required.
> Lastly, under extensions, "For each instance of a non-standard node,
only the fields written as part of that instance need to be described in
the fields[] specification; that is, fields that arened written because
they contain their default value may be omitted from the fields[]
specification."
>
> 1. "fields[]" doesnt specify defaults.
Right. So if you get a node:
Foo { fields [ SFFloat f1, SFFloat f2 ] f2 10.9 }
... the declaration of f1 is superfluous; there's no reason to declare it,
since it has its default value (what that value is you don't know unless
you can find an implementation of Foo, but again, you don't need to know).
> 2. defaults are currently part of the implementation and specification.
The extensibilities of the language must be self-defining, not
implmentation specific. If someone wants to define defaults for a "foo",
then I need the fields and the defaults.
Why do you need the defaults? What can you possibly do with a Node that
you know nothing about?
> Am I out in left field here? *grin*
No. Depending on how behaviors are done, this might become an issue (but
I don't think it will, because I think that fields are internal, private,
persistent state of nodes, and should be accessible only from within the
node's implementation).