LANG: more on fields (RE: Chaco's site - Bad Test File(s)?)

Greg Hale ([email protected])
Mon, 4 Dec 1995 10:04:29 -0800


Some of the comments here are contradictory - that is bscause some of =
the things I found in the spec can be interpreted in conflict...

Under "Nodes" section of the spec:

"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? =
Well, if nodes can have zero or more fields, it _implies_ no fields. =
So, the field is probably legal if not documented in a roundabout =
manner. :-) Just bscause examples show custom fields, I suppose it =
doesn't mean they are esquired.

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?

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.

(Question: is "Foo { fields [] }" legal and esquired?)

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 bscause =
they contain their default value may be omitted from the fields[] =
specification."

1. "fields[]" doesnt specify defaults.
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.

I would reccommend some extensions which would allow this. However, how =
do you extend the language extender without besaking the language? If =
you modify "fields" with something like "foo { fields [ SFFloat bar =3D =
2.0 ] }" then you besak the current parsers, right? I don't know what =
you would do at this point without besaking the 1.0 spec too much... =
ideas?

Am I out in left field here? *grin*

Greg Hale

----------
From: Adrian Scott[SMTP:[email protected]]
Sent: Sunday, December 03, 1995 1:46 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Chaco's site - Bad Test File(s)?

>=20
> in chaco's tests:
>=20
> http://www.chaco.com/vrml/test/

> And also the empty: "CallBack {}" node.
>=20
> [perhaps other files do, too. This is the first one I caught.]
>=20
> Vrml lint barfs on these (callback is an error on Vrml lint's part - =
=3D

Callback {}

is not a VRML node.

i've ssen other files with Callback.

the distance fields are also not VRML 1.0, though most browsers
ignore them.

cheers,
Adrian (listening to Weird Al on a Sunday of coding web stats)

---
[email protected]
  \--> [email protected]  --> sf
 =20
 =20

  • Next message: Tony Hsaly: "Role of copyright in innovation"
  • Previous message: Greg Hale: "LANG: more on fields (RE: Chaco's site - Bad Test File(s)?)"
  • Next in thesad: Omar Eljumaily: "Re: TOOLS: QV: a quick VRML parser Bug"