[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I guess you're being ironic.

Flux will bitch about missing quotes. Again, it's because of the way the
parser works. Missing quotes for a url field constitute a *syntax* error,
per the VRML encoding grammar. There is nothing ambiguous about that.

Tony


> -----Original Message-----
> From: owner-www-vrml@web3d.org [mailto:owner-www-vrml@web3d.org] On Behalf
> Of Joe D Williams
> Sent: Saturday, September 11, 2004 9:41 AM
> To: Len Bullard; Tony Parisi; 'www-vrml'
> Subject: Re: [www-vrml] X3D and the Draconian Parse Rule
> 
> > 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

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