> > * Clarification for unquoted strings:
> Agreed
I agree too, strings should all be surrounded by double-quotes.
> > * Multilined SFStrings: According to ANSI-C as intended for SFFloats,
> > linefeeds should be made explicit using "\n",
> I don't think this adds anything.
I agree with Mitra here, minimal functionality for the effort...
> > * Clarification for AsciiText: There should be a statement about the
> > apperance of SFStrings containing linefeeds:
> Agreed - I think they should be taken into account, but either is possible.
Yup.
> > * SFBool according to ANSI-C: SFBools should also be TRUE if any value
> > unequal 0 is detected.
> No - TRUE is 1 FALSE is 0, any other value should be a syntax error
I think ONLY TRUE/FALSE should be allowed for SFBools.
> > * Clarifications for fields: field-types are always one of the SF- or
> > MF-types mentioned in the current spec. Nodes aren't allowed for
> > fieldtypes.
>
> Yes - this has always been true!
Mitra's right.
> > * Clarifications for SFEnum: either give users a way to define their
own
> > mnemonics for SFEnums of derived user-node-types (if so, it makes
sense
> > to apply the feature to SFBitMasks too) or else restrict SFEnums
> > explicitely to the values defined in the specification (see
> > example-rules above).
>
> Yes - this is definately required for adding extension nodes.
Here I disagree with both of you. A parser should be able to deal with:
#VRML V1.0 ascii
NewNode {
fields [ SFEnum enumField ]
enumField AN_ARBITRARY_ENUM
}
The syntax of an SFEnum field is regular-- you don't need to know the
possible values to parse it. WebSpace, for example, has no problem reading or
writing the above example.
> > * Clarifications about SFBitMasks: Should SFBitMasks of one class be
> > restricted to fit into an SFLong (32bits)? Given a way to define
one's
> > own mnemonics, there should be a way to combine several values into
one
> > mnemonic, as in the example-rules above).
>
> The bit lengthof this should be clarified since it can be used by extension
> nodes.
OK-- but same arguments as for SFEnum, there's no need to define the allowed
values of the mnemonics in the VRML file.