[Tim is getting an extra copy of this because I haven't yet seen
the results of the vote on list behavior.]
Tim Bray wrote:
| At 02:07 PM 19/06/97 -0400, B. Tommie Usdin wrote:
| >It seems to me that is really a political question, or perhaps a
| >theological one.
|
| Except for this sentence, I agree with the rest of Tommie's posting.
| I want to lose PE's and am willing to accept that for people who need
| to live in a complex-DTD world, they'll probably have to use Full SGML.
Ah, so XML is not only something that obdurate B.S.'s can code
parsers for in a week, it's something that's fundamentally unscaleable.
Now I understand.
| But Eve is correct, I think, in saying that namegroups in declarations
| do replace one or two common PE usages.
Not in functionality or utility.
| My willingness to make the the trade-off is because despite really a lot
| of work by myself and (even more) Michael, the PE section of the XML-lang
| spec is blatantly hideous compared to the rest of it. It is hard to
So rewrite it. These are macros, right? CS grads understand macros, right?
| explain, hard to understand, and hard to implement. It needs a supporting
| section in an appendix to try to "explain" it (always a bad sign). It is a
| psychological barrier to the acceptance of descriptive markup.
? There are no p.e.s in an instance except as marked section keywords
(if still allowed there). We're not talking about markup but the
specification of markup.
| Partly because this because the current PE reference replacement rules
| are arguably B.A.D. (broken as designed) - Michael and I came up, I think,
| with a significant innovation in specification tactics in the use
| of the %-operator, and the result is still very very complicated.
I find the "%-operator" almost prevents me from reading the BNF. Your
argument here is that you can't explain a perfectly clear concept
clearly, so you want to drop it. This is not a suitable argument to
make to the WG whose time you are uptaking.
Regards,
Terry Allen Electronic Publishing Consultant tallen[at]sonic.net
http://www.sonic.net/~tallen/
Davenport and DocBook: http://www.ora.com/davenport/index.html
T.A. at Passage Systems: terry.allen[at]passage.com