I don't think we should make this part of our proposal. The
VRML community as a whole will have to come to some consensus
on this matter, probably a recommended praxis.
>
> 2)
> Another serious problem we MUST solve before entering into
> writing our proposal is that we should specify clearly
> the scope of node names.
The scope of node name should be the same as in VRML 2.0
specifification, but in addition whenever a node name is
visible so are its fields. If the type of a field is
a subtype of SFNode then we can again access a field
of its value, but only those which are known via its
type, e.g.
CLASS A EXTENDS SFNode [ field A next NULL ]
DEF Foo A { next A { next A { } } }
DEF Foo2 A { next Foo.next.next }
But for example
DEF Foo3 Transform { children Transfrom { children A { } } }
does allow to access Foo3.children
but not Foo3.children.children
because the field children is of type MFNode and
MFNode has no default fields.
Cheers
-- Stephan
---------------------------------------------------------------
Dr. Stephan Diehl Tel.: ++49-681/302-3915
EMAIL: diehl@cs.uni-sb.de WWW: http://www.rw.cdl.uni-saarland.de/private/diehl
---------------------------------------------------------------
There is no place like $HOME
---------------------------------------------------------------