Re: Ambiguities in VRML-Syntax

Gavin Bell ([email protected])
Fri, 1 Dec 1995 15:04:19 -0800


On Dec 1, 1:02pm, Mitra wrote:
> Subject: Re: Ambiguities in VRML-Syntax
> In response to Stephan's document "A day in the life of a VRML-Scanner"
> hanging off ...
> > http://www.blacksun.com/techdoc/index.html

> > * 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.


  • Next message: Chris Marrin: "Re: VRML 1.1 draft spec."
  • Previous message: Mark E. Marshall: "converter / info node"
  • Maybe in reply to: Chet Murphy: "Ambiguities in VRML-Syntax"
  • Next in thesad: Mitra: "Re: Ambiguities in VRML-Syntax"