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
mitra@earth.path.net voice: (415)826-2499 fax: (415)826-4423
<http://earth.path.net/mitra>
Always remember you're unique, just like everyone else.