Re: Recent ERB votes
At 12:28 AM 11/7/96 EST, firstname.lastname@example.org wrote:
>> What's wrong with, e.g.:
>> <?XMLEmpty BR HR IMG>
>> to list the empty elements? The "new syntax" doesn't seem so difficult,
>> and I see no more possible inconsistencies than are inherent in any
>> markup scheme. Whether you also allow the <e/> syntax is an orthogonal
>> issue, but I personally would find the "new <e/> syntax" more of a bother
>> than a simple PI with a list of empty elements, and would rather not have
>> to worry about explaining or handling it.
>If you come at it from an SGML viewpoint, I agree with you.
>If you come at it from a quick-perl-hack or a short-C-program point
>of view, having EMPTY elements marked is such a big win I can't
>even begin to describe it. It's the difference between being able to
>write something useful in under ten minutes, and taking a day or two
>or not doing it at all.
I agree. Furthermore, I'm more than a little troubled by PI kludges of any
kind for parsing. In general, aren't PIs application level information? The
notion that a XML parser (as a potentially independent/separable
module/program) needs to peek into PIs, strikes me as just the kind of poor
comments. OTOH, if we kept it clean, we'd still require (i) every
application to call back into the parser to inform it about a <?XML ...> PI,
and (ii) this round trip would have to occur before any further parsing. All
of this (in an effort to be clean) puts even greater burdens on the
app/parser interface/API; to take arms against this sea of troubles,
programmers *will* take the kludge short-cut -- and open the gates to all
sorts of PIs for parsers to peek into and act upon.
>Frankly, this HTML compatibility thing is a total waste of time.
>We've argued long and hard for empty elements to be marked as different,
>so that they can be parsed easily, reliably, and without a DTD.
This is the crux of the matter, IMHO.