Re: Parameter entities vs. GI name groups

On Fri, 20 Jun 1997 14:48:56 -0400 (EDT) Tim Bray said:
>Sigh.  My fallback position has always been, can we banish
>PE's from the internal subset?  The idea is, even if PE's
>are agreed to be necessary for validating applications, I can
>see no good argument that a lightweight DTD-less WF doc
>reader should ever have to deal with them.
>
>As for the difficulty: I (and I think I'm not alone) am
>sensitive to issues of parser size.  Processing PEs is not
>rocket science but will materially add to code bulk.  Part
>of this code size is code that checks that the PE began and
>ended at a legal place [which code SERVES NO USEFUL PURPOSE
>FOR MAN OR BEAST]

Do you write code 'that checks that the open paren and close paren
occurred at legal places' too?  I suppose it's possible to build parsers
that way, but the parser methods I've used (yacc and recursive descent)
enforce bracketing rules without requiring ad hoc rules.  If you treat
the % operator as naming a sort of non-terminal-with-inline-rhs, then
your grammar will automatically do the job for you.

But in any case:  if you're writing a non-validating parser, why are you
concerned to catch PE errors in the first place?  A non-validating
processor has to handle valid and well-formed documents.  Why does it
have to catch PE errors?

The only reason I can see is that matching the DTD rules is defined as
part of well-formedness, and we made well-formedness errors reportable.
Change that (how?), allow non-validating parsers to use macro-expansion
techniques for PEs, and your problems go away, right?

-CMSMcQ

Received on Friday, 20 June 1997 16:08:00 UTC