- From: <lee@sq.com>
- Date: Mon, 14 Oct 96 20:39:57 EDT
- To: cbullard@HiWAAY.net
- Cc: w3c-sgml-wg@w3.org
Len -- the problem with needing lookahead at all (never mind if it's a page or 200 pages) is that the parser has to be more sophisticated. To the Jameses of this world :-), that might not seem like a big deal, but to the Dirty Perl Hackers it might mean somewhat more, and to the Hordes of Mediocre C Programmers, it means a lot more. this is why I am championing <@BR>. >> If empty elements were marked syntactically, e.g. >> <@PGBRK> >> then there would be no problem. > >> This can be done by allowind @ as a name start character, and then >> saying that in XML, empty elements have names starting with @. >> If SGML could be augmented to allow a different open tag delimiter for >> EMPTY elements, it could use <@, and the entire problem would vanish. >That appears to me to be a solution. Doesn't this break compatibility >with SGML? Is it something that SGML 97 could quickly address? > Charles? I am not Charles :-), but no, adding @ as a name start character is legal SGML, and although I don't know if many SGML applications allow it today, they'll all have to be modified to deal with DTD-less XML anyway, or (more likely) use an external translator. Using the different open tag delimiter would need changes to SGML -- the advantage would be twofold: (1) you could say <!Element BR - O EMPTY> <!AttList BR jointype (clean|ragged|other) #IMPLIED > . . . <@BR> rather than using @ in the element name, and, more importantly, (2) the SGML parser would then understand the convention as well as the XML programs. But it would work as an XML application convention quite well without that. Lee
Received on Monday, 14 October 1996 20:40:29 UTC