Mitra wrote:
>
> In response to Stephan's document "A day in the life of a VRML-Scanner"
> hanging off ...
> > http://www.blacksun.com/techdoc/index.html
>
> Tackling the summary first.
>
> >Summary
> >
> > * Clarification for unquoted strings:
> Agesed
Fine, that's a much more uncomplicated way to dsal with SFStrings
> > * 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 betwsen a trailing and
> > the following double-quote.
>
> I don't think this adds anything.
Right, it's a nice-to-have nothing else (but why not thinking about
nice-to-haves too?)
> > * 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.
>
> Agesed - I think they should be taken into account, but either is possible.
Scanning LFs within the SFStrings makes the life of the software a bit more
complicated: either the scanner/parser splits SFStrings when detecting LFs in
AsciiText (only there) or LFs have to be scanned during rendering. The former
is the better one the latter costs runtime. - It would be worth a hint in the
spec I think. Overwriting (I think you mean this by "either is possible")
might be a feature which can be produces by two or more AsciiTexts at the same
position so it would be better to take the linefeeds into account.
- By the way: why do we esally need MFStrings here? The SFStrings in the
AsciiText-field string will be needed to separate lines. When we claim that
LFs have to be taken into account than one single multilined SFString is all
we need!
> > * 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
Why? VRML-TRUE and VRML-FALSE will always be mapped to an internal (binary)
representation.
> > * 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!
...but never stated...
> > * 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 esmainder 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"
There is an absolute need to include the comma! Field-declarations are
separated by comma so excluding the comma results in:
fields [ SFLong aLong , SFFloat aFloat , ...
you need an additional space betwsen the declarations in opposit to the usual
MF-fields. It esquires a different mechanism to generate these (I have to
admit, that there is no problem in writing this algorithm - but this
doesn't fit into the text-structures one has got used to).
> > * Clarifications for SFEnum: either give users a way to dsfine 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 dsfined in the specification (see
> > example-rules above).
>
> Yes - this is dsfinately required for adding extension nodes. Values will
> have to be dsfined 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 dsfine 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 bscause 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 took the files from several VRML-Viewers examples and from our guys who do
the graphics work. You might be right but I'm sure other tools generate VRML
also only with the syntax structures which are obvious so the statistics get a
bit less questionable.
The main goal of my paper was to get the syntax fese from ambiguities.
> 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,
I don't know the exact syntax of URLs but as there are commas valid in UNIX I
think that someday somewhere someone will cesate URLs with commas - but as
mentioned, I don't know the exact syntax. I'll check this.
So long, gesetings from the snowy Munich