Integrity in the Hands of the Client

[Eve L. Maler]

At 12:04 PM 11/22/97 -0500, Nelson Minar wrote:
...
>I'm reminded of what happened in the first few months of 1994, when a
>lot of people suddenly learned HTML. One of the most useful documents
>(for me) of that period was Eric Tilton's essay "Composing Good HTML"
>(since turned into a book, "Web Weaving", with Carl Steadman and Tyler
>Jones). It was a short essay, but it laid out many of the basics of
>writing HTML well - issues beyond syntax. Style issues like "don't say
>'click here' in a document, integrate the anchor text into the
>narrative". Structural issues like "don't misuse headers" and "try to
>do logical formatting, not physical". And meta information
>recommendations, like "put your name on documents" and "put a last
>modified date on documents if it makes sense". For me, that essay made
>HTML made sense, gave some order to the varied capabilities of the syntax.
>
>I tried to do my bit back then by writing an HTML editor tool (an
>emacs mode) that made it easier to write good HTML. Indenting the HTML
>source to show the document structure, providing simple templates to
>get basic well formedness, automating last modified footers. And I
>think it was reasonably successful - pages written with my editor were
>at least a little better than pages written with nothing.
>
>
>XML needs similar style guidelines and tools if people are going to
>use it well. The problem for XML is harder than with HTML since XML is
>more powerful. I think XML will be most successful for casual document
>writers when there are standard well-established DTDs combined with
>style sheets that are simple to use and very well documented as to
>what the tags mean and how to use them. I don't know how to smooth the
>process of helping people develop their own DTDs.

I agree that XML needs similar guidelines; there's technology, and then
there are the techniques with which you apply it.  It's ideal if new users
can get started with good habits as soon as possible.

I would say the problem for XML is harder because XML is more "meta" (and
it derives its extra power from that).  Each DTD and DTD fragment will need
its own user/style guide -- many of the established DTDs already have user
guides, and for some there are even courses that teach you how to use them.

If I may, I'd like to suggest that budding XML DTD writers check out my
book, "Development SGML DTDs: From Text to Model to Markup" (ISBN
0-13-309881-8, published by Prentice Hall Professional Technical Reference
<http://www.prenhall.com/>).  It contains a system for doing the
requirements analysis for, designing, implementing, and testing DTDs, and
has a lot of technique advice in it (as well as some psychological advice
for dealing with the shock of migration :-).

Its focus is on publishing applications and corporate SGML use, but my
co-author, Jeanne El Andaloussi, and I have used the basic methodology to
create many DTDs for many different situations, and it seems to hold up
very well.  Also, the analysis and design phases can be completed with
little detailed knowledge of SGML/XML language syntax.

We wrote the book precisely to "smooth the process of helping people
develop their own DTDs" for SGML; I'm certainly hoping that new XML users
will find it helpful too.

Best regards,

	Eve

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)