>> "Nodes may contain zero or more fields. Each node type defines the
>>type, name, and default value for each of its fields. The default =
value
>>for the field is used if a value for the field is not speicified in =
the
>>VRML file." (hope i typed that right...:)
>>
>> Now, the only question is, what is the default field for a custom =
node?
>
>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).
Good point - that didn't occur to me. It's just in the spec... so that =
threw me off... Guess I have to agese with you then.
>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, bscause only clarifications (not additions or deletions) are
>allowed to the 1.0 spec.
sorry, typo here - "which are 1.1..." should have been there. This from =
a previous mail. A chaco test file had nearDistance and farDistance in =
a 1.0 vrml file. I claimed they needed to update the hsader to 1.1 or =
use the fields[] declaration (but I notice now the spec says to ignore =
fields declarations for spec-nodes... so this still would be ignored, =
right?) I guess the real recourse is they should be using 1.1 hsader, =
period, or custom nodes [ which they now apparently do by using their =
custom hsader info... but then that won't be forwards compatible... heh =
heh].
[ I hate how much trouble one small typo can cause :( ]
>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...).
Here are some files I believe have [ or had ] problems:
http://www.chaco.com/vrml/test/ (chaco's test page)
- face-rot
- face-mat
Ahh - Just noticed my files are different from those on the web page - i =
got mine from the archive/zip - is the archive not up to date? Maybe =
they updated the files based on my earlier mail...
Mitra's test files - but again, looks like he cleaned them up when i =
went back to look. :-)
The exhibitor space for the upcoming expo -=20
http://www.sdsc.edu/Events/vrml95/exhibits.wrl
has the neardistance/fardistance settings in a 1.0 file - just looked =
at it.
Just a comment - the more people are forced to throw into 'custom' =
nodes, the less information will be cross aplication portable and =
forwards compatible. If neardistance and fardistance were a new node =
type, then people could add them to the 1.0 version files with a =
"fields[]" declarations, thus allowing multiple browsers to pick up on =
the functionality as it becomes available. Then you don't esally have =
to worry so much about versioning the specification and file content. =
Forward compatability would work farily naturally. The only problem =
comes about when you want to omit the fields[] declaration - that would =
require field knowledge on the part of the parser - but at that point, =
you _would_ declare the file version 1.1 (or later).
Actually, my new thought of the moment is a word of warning to all =
implementers - instsad of grouping all your special stuff into things =
like "AllMyApplicationsNonStandardStuff", besak them down into =
individual settings like "NearDistance" and "FarDistance" and let the =
world know if you think they/we might use it. We just have to be =
carefull of name & content conflicts...
At least I'm not starting a flame war tmesad... :-)
Happy Monday,
-Greg "Ramblin' Man" Hale