RE: [www-vrml] X3D and the Draconian Parse Rule

["Len Bullard" <cbullard@hiwaay.net>]

So Flux will honor the well-formed parse requirements
but given good syntax and bad structure will not render
the badly structured portion of the scenegraph.  It
will make a best attempt to render the rest and issue
a warning.

If the specification is silent about that, it is vendor's
choice.  In an authoring context, it seems sensible to
be strict and in the published context, friendly.  My
question initially concerned the consistency among the
encoding parse rules.  I wasn't a big fan of the Draconian
parse rule when it was introduced to markup, but the good
sense of it became clear as I watched very skilled
programmers tackle XML middleware and realized that hiding
bad syntax made their jobs harder, that they would take
that as a challenge, would fix it in code, and as a result,
bad data would fill up the system.  Good intentions and
the road to hell...

len


From: owner-www-vrml@web3d.org [mailto:owner-www-vrml@web3d.org]On
Behalf Of Tony Parisi

Flux will always do its best to render something. That's our product
philosophy, pure and simple. It should be friendly to the end user. And
stopping operation because a Box isn't under a Shape node isn't friendly--
in fact it's downright hostile. For that, a warning can be issued. (However,
I don't believe there should be an obligation to try and *render* that box.
I think ignoring it is a fair outcome.)

I believe warnings are an appropriate response to most erroneous content. I
am also considering a "strict conformance mode" for Flux, that *would* bitch
and stop operation, but *only* for use during development time. That would
help developers avoid errors before they ever deploy. But to me, that's a
development tool feature, not a browser sine qua non.

The above being said, there are some things that simply won't render in
Flux:

- badly formed XML - the XML parser I use will throw up before I can even
render the stuff;
- bad VRML97/classic syntax - Flux uses a strict YACC-based grammar and if
the *syntax* is bogus there isn't much to be done.

These are the result of engineering decisions: it would be more difficult to
develop a browser that is resilient in the above ways. However, given a
toss-up on the engineering issues, I opt for being friendly. So, in the
above Box case, it's equally easy to ignore it as it is to stop... therefore
I think it best for Flux to ignore the aberration and try to render the rest
of the Scene.

-------------------------------------------------------------------------
for list subscription/unscrubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html