[
Lists Home |
Date Index |
Thread Index
]
That's one. I'll agree that if one is doing a
lot of conversion work, it might be best to slip
back to SGML and use the power tools. The example
you give is interesting in terms of a production
flow in and out of DTDs where each DTD describes a
state in the production process. In the web
industry were better informed, SGML expertise would
be one of the things to check when discovering a
company and considering it for conversion work.
I have done "ugly" conversions, but we did not
use that technique. I admit to thinking more
in terms of documents with longer lifecycles
rather than short, stepped versions. I think
the handbook got it right though in saying that
techniques such as a fully minimized element
are for those who completely understand the
contexts of the declarations. Otherwise, as
it also says, valid SGML can be produced that
does not match the intent of the designer.
Since we often design for people who barely
bother to understand what the brackets are for,
using a fully minimized element seems risky
unless one has full control of all the places,
people, and processes in which it is used.
For a web DTD shared outside a closed system,
it seems even riskier. OTOH, the HTMLers
used it. It may have worked simply because
the tag stackers ignored the DTD in most cases,
and when they did bother to validate, the DTD
proves so loose as to almost be worthless.
That's an interesting rabbit trail in and
of itself: how useful has HTML validation
and the HTML DTD proven to be other than being
a formal description of the tags in the soup?
len
From: Marcus Carr [mailto:mcarr@allette.com.au]
Bullard, Claude L (Len) wrote:
> *Bonehead elements* might be good. Other than in
> the SGML Handbook, I've never seen these used
> in practice.
You haven't spent enough time around ugly (read "cost effective by
coding alone") markup jobs then. I've used omissable start and end tags
more times than I could count - the classic situation is for turning
something like:
<section>Laundry basket
<para>The laundry basket has a long and fascinating history...
into something like:
<section>
<title>Laundry basket</title>
<para>The laundry basket has a long and fascinating history...
It's intuitive, equivalent and less markup. I'm surprised that there's
so little enthusiasm for this - I've had markup teams ask for this sort
of change to be added to a DTD. Omission is one of the key drivers that
has kept us using SGML en route to the delivery of XML data. Normalizers
are cheap, markup people aren't.
|