Re: B.10 Empty elements?

John_Lavagnino@Brown.edu wrote:

> Since this question remains open, as far as I can tell, let me just
> log another favorable response to the <e/> idea, which I think was
> originally advanced by James Clark.  It looks and feels more natural
> than <e/ by having the universal tag-ender >, while also containing
> the / which suggests end-ness to us all; it doesn't make the user feel
> irritated the way <long-tag-name></long-tag-name> is going to do;

I agree.  I admit I still like <@this> best, but <this/> would work as well.
As would <this!> I suppose, which hass a nice imperative feel to it...

> and by differentiating the EMPTY elements even without a DTD it tidily
> resolves the problem of knowing what's going to have an end-tag and
> what ain't.

All except the partial-or-implied-but-included DTD suggestions have
that property, I think.

If there were no attributes, a syntax would be possible like
<p This is a paragraph, with just a <emph little> emphasised text in it.>
which gets dangerously close to LISPing to be accepted by the Agnosticks.
Similarly, good old Scribe with @nostalgic{stuff like this}.  Erik Naggum
once sent me an SGML declaration to make @begin(x) ... @end(x) legal, but
couldn't also allow @c{....} in the same declaration, I think.

But if we change to something too craftily-fashioned, it won't look like
SGML or even the SMLG that's used by so many in the congregation, and
we shall all be shunned like a Welsh pub during Evensong.

<P>So we look like <emph>this</emph>.</P>

And then our syntax has a problem with empty elements (that the others
I showed needn't have),<BR/?!#$@?>/;
so we compromise.

It's important to try and see where compromise is acceptable, and where
it will lead to failure.  If the drummer is in 2, the sax is in Gflat m,
and the violin is doing a waltz in A, we can all compromise on a tango
in D flat minor, but we can't compromise on 2/3 in Gflat-and-a-half, and we
all have to end up playing the same tune.  Modulo counterpoint, OK.

So we can use <e/> and understand that existing SGML parsers will break,
but w'll try and fix that by changing SGML and hope that at least some
of the commercial SGML parsers are updated -- maybe most of them.
(or can this be done without breaking things?  I don't see how, although
if James said it could, he is right, and I have just forgotten!)
(oh, OK, a shortref or datatag mapping to > perhaps?)

Any of <@emp>, <emp>/, <emp/>, <emp!> require at the very least a
change to the SGML declaration, but as we've already increased NAMELEN
that's probably OK.  Not all things can be changed in today's commercial
SGML parsers; some of them are more flexible than others.
Some basically ignore the SGML declaration altogether (e.g. Panorama),
although I shouldn't be surprised if we modify Panorama to handle XML
in some way anyway.  You could say that if a given product doesn't
support all of whatever one thinks of as the basic set of SGML features
(e.g. if its SGML feature set number has too few bits set) tht it isn't
an SGML application.  If SGML were simpler, more applications would
conform -- hence the need for XML.

It's thus not clear to me -- and has never been clear to me in these
discussions -- how much importance to give to "existing SGML applications
can read the data" vs. "existing sGML applications can be tweaked or
modified to read the data".  If you need to change the SGML declaration,
chances are you'll break most of the different existing SGML parsers in
use today -- although not most installations, a a few parsers count for
most installations -- James' SP and SoftQuad's (in HoTMetaL and A/E)
might be the most widespread, with Synex (ViewPort) -- although Synex
don't claim to use a validating parser -- probably next.  Those numbers
are high because of the web; I'd put EBT up there except that I think
most of the DynaBooks out there are reading the compiled format, and of
course several other vendors are represented on this list, or are well
known in the SGML community.  So maybe all those parsers can be changed,
where they don't already handle changing delimiters (they certainly don't
all handle SHORTREF, DATATAG, SUBDOC, CONCUR and LINK).

Michael, John (if you're still here after so much incoherence) -- is that
a fair question?  I'm not sure if it's appropriate for this list, but
presumably no-one in the SGML world is yet committed to doing any
implementation work for XML.  Is it worth investigating who is prepared
to do (very roughly) how much?  I'd rather not do that, since I'm not
exactly independent from SGML vendors...!

Lee

-- 
Liam Quin, lee@sq.com         | lq-text freely available Unix text retrieval
Senior Technical Consultant   | FAQs: Metafont,OPEN LOOK UI,OpenWindows
SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView)
http://www.softquad.com./   http://www.softquad.co.uk./

Received on Wednesday, 23 October 1996 01:21:51 UTC