>
[going off at a bit of a tangent here...]
The problem I can see with not declaring all the fields is the case where
someNode2 {
In this case, if the browser knows about a "someNode2" then it uses all
What my original query was about was the _ordering_ of the isA field
> > 3) The MFString type, while being a logical extension to the SF/MF
Yup, I know, it's just that while SFFloat/MFFloat, SFLong/MFLong etc are
> > 1) Is there any requirement for the isA field to occur before other fields
> > (except perhaps for the 'fields' field)? It make
> > there is such a requirement, as you don't need to store the values of all
> > fields as you parse an extension node. I have a feeling, looking at the
> > sample node
> > might be a good idea to make it explicit in the 1.1 spec.
>
> my question of some time ago (which got no reply) was along a similar
> line ; by introducing the isA field, the new node inherits the fields
> from (multiple) parents. Therefore, should these be declared
> (again) in the fields definition within the new node? I say they
> should not - the whole point is that by declaring the node is based
> on some standard type, any parser/run-time not capable of
> understanding the new type can take some gui> as how to interpret
> the node otherwise. For example
>
> blueGlass {
> isA "Material"
> fields [ MFFloat refractiveIndex ]
>
> diffuse 0 0 1
> refractiveIndex 1.1
> }
>
> could be rendered opaque if a renderer cannot support refraction -
> the Material fields are implied from the "isA" statement.
there are several isA nodetypes specified e.g.
isA [ "someNode1" "Sphere" ]
fields [ SFFloat radius, SFString usedby1, SFString usedby2 ]
radius 3.0
usedby1 "abcd"
usedby2 "efgh"
}
fields and ignores both the fields [] and the isA []. If it knows about a
"someNode1" then it uses 'usedby1' and uses the fields [] to interpret
'usedby2'. If it only knows about "Sphere" then it gets info on _both_
usedby1 and usedby2 from the fields [] ... so what should be in the isA?
The lowest common denominator? IMHO whatever you do you'll need some code
to ignore defs in the fields [] that you already know about, so this
shouldn't be too much of a problem if all fields are defined. As it is,
parsers are required to silently ignore the definition of fields for
standard node
.
within the node : in the specification, there is no requirement for the
isA field to come before the actual node fields themselve
. IMHO there is
nothing to be gained by allowing this behavior, and since there is
already a restriction that the fields field must be the first field after
the {, why not just add (or clarify - AFAIK this was what was intended
originally) this requirement explicity.
> > convention, needs to be defined explicitly.
>
> The name says it all. M=multiple, therefore MFString = multiple
> strings, seperated by comma's and enclosed in [ ] as with all other
> MFtypes
>
set out in the spec, MFString was missed.
--
Oliver Jowett Student, programmer-at-large,
[email protected] and generally nice guy.. ;-)
--------Time flies like an arrow. Fruit flies like a banana.-------