Lists Home |
Date Index |
- From: Tim Bray <firstname.lastname@example.org>
- To: Trevor Jenkins <email@example.com>, firstname.lastname@example.org
- Date: Mon, 18 Aug 1997 16:22:52 -0700
At 09:52 PM 18/08/97 +0000, Trevor Jenkins wrote:
>convinced that as they stand the separator rules in XML are
Yes; Michael Sperberg-McQueen and I both agree that these need
some more work. If it weren't for the $#*!@#%#!ing Parameter
Entities, all this would be simple and straightforward - designing
a grammar for the SGML element declaration language is not exactly
But when you try to pollute the grammar by saying where you can
and can't replace chunks of it with PE references, it all of a
sudden gets hideously difficult. SGML gets around this with the
clever device of the Ee (entity end) virtual token... which we in
the XML gang thought was hopelessly unaesthetic; after some struggles
with this particular problem, Ee is starting to look better.
Mind you, of the 3 XML-lang co-editors, two (I and Jean Paoli) have
voted against the existence of PEs at every opportunity; these votes
are in some part self-serving. However, there can be no doubt that
if you want to build and maintain 8879-style markup declarations, it's
basically just not possible to do this without PE's. Sigh. Mind you,
some of us have another solution for that...
Another compromise would be to apply the internal-subset rule, i.e.
you can have PE's but they have to replace whole declarations. There
are other interim measures, i.e. you can only replace a whole content
model; all involve severe limitations on PE usefulness as the payment
for spec/grammar clarity.
Anyhow, further grammar engineering is in order. One thing to
think about is simply to drop the 'S' (space) nonterminal, write
a couple of simple tokenization rules, and take it that way. CMSMcQ
has investigated this at length, but it has problems too.
Pardon me for whining; I'm sure we'll figure out something. -Tim
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)