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

["Joe D Williams" <JOEDWIL@earthlink.net>]

> Good intentions and the road to hell...

The choices come very early, like the item of
["..."]
and
"'...'"

lots of VRML97 allowed
url "..."
when the spec clearly showed
url ["..."]
was required because the value is an MF.


So the X3D XML can be:
"'...','...'" or '"...","..."'

and the X3D Classic VRML can be
["...","..."]

If the MF is just a single field, it is very friendly
to allow dropping the outer quotes...

Best Regards,
Joe




----- Original Message -----
From: "Len Bullard" <cbullard@hiwaay.net>
To: "Tony Parisi" <tparisi@mediamachines.com>; "'www-vrml'" <www-vrml@web3d.org>
Sent: September 11, 2004 9:24 AM
Subject: RE: [www-vrml] X3D and the Draconian Parse Rule


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

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