Re: Ambiguities in VRML-Syntax

Mitra ([email protected])
Fri, 1 Dec 1995 13:02:43 -0800


In response to Stephan's document "A day in the life of a VRML-Scanner"
hanging off ...
> http://www.blacksun.com/techdoc/index.html

Stephan, Thanks for your well thought out critique and proposal. There are
some things where I agree entirely, others which are dealt with (in your
way, or another) in VRML1.1, and others which I'm less sure of the benefit
of.

Tackling the summary first.

>Summary
>
> * Clarification for unquoted strings: either drop them completely (see
> statistics above: not a single occurence throughout 746 occurances of
> SFStrings in 131 more-or-less randomly selected files), or else add
> some additional words to the spec, clarifying the quirks of unquoted
> SFStrings especially in the context of MFStrings (are commas and
> closing square brackets allowed, should strings include
> quote-characters similar to their quoted siblings etc...)

Agreed

> * Multilined SFStrings: According to ANSI-C as intended for SFFloats,
> linefeeds should be made explicit using "\n", SFString-continuation
> according to ANSI-C if only whitespace is found between a trailing and
> the following double-quote.

I don't think this adds anything.

> * Clarification for AsciiText: There should be a statement about the
> apperance of SFStrings containing linefeeds: either those must not
> contain LFs or they have to be taken into account when drawing the
> text.

Agreed - I think they should be taken into account, but either is possible.

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

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

> * Clarifications for the syntax of VRML-identifiers: The syntax should be
> restricted to a syntax like the one mentioned above. That wouldn't
> effect most of the current VRML-files.

VRML1.1 proposed language is:

Field names start with lower case letters, Node types start with upper case.
The remainder of the characters may be any printable ascii (21H-7EH) except
curly braces {}. square brackets [], single ' or double " quotes, sharp #,
backslash \
plus +, period . or ampersand &

Node names must not begin with a digit , but they may begin and contain any
UTF8 character except
those below 21H (control characters and white space), and the characters {}
[] ' " \ + . and &.

VRML is case-sensitive; "Sphere" is different from "sphere"

> * 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. Values will
have to be defined for
standard nodes at some point so that behaviors can set them explicitly.

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

In more specific ......

Your statistics are a bit questionable because the files are probably
produced by a small set of tools at this point. In particular IsA isn't
supported by the browsers which explains its absence.

I have open questions about URL, I've argued for SFURL and MFURL which
would allow for syntax checking of the string. Also, I don't believe
commas are valid in URLs,

- Mitra

=================================================================
Mitra
[email protected] voice: (415)826-2499 fax: (415)826-4423
<http://earth.path.net/mitra>

Always remember you're unique, just like everyone else.


  • Next message: Anders Vinberg: "Jaron Lanier"
  • Previous message: Kitainik, Leonid: "HAPPY THANKSGIVING WITH LOVE FROM PARAGRAPH!"
  • Maybe in reply to: Chet Murphy: "Ambiguities in VRML-Syntax"
  • Next in thesad: Adrian Scott: "Re: Ambiguities in VRML-Syntax"