Re: [FrameSGML] Re: Frame+SGML Tutorial?

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Ah, one of my favourite topics - analysis is really the heart of any SGML
implementation.

Dan Emory wrote:

> Each expert was given a year's worth of the magazine's issues, and was asked
> to estimate how long it would take to develop a DTD. Each of them took more
> than twice as long as their estimate. When the finished products were
> analyzed, virtually no resemblance was found among the five resulting DTDs.

I don't think that it's important that they be similar - the metrics by which I
would judge their appropriatness would deal with whether they capture enough
information to ensure that the data will be useful into the future. As that's not
possible to quantify, I'm not that surprised that the results differed, though I
would expect that the boundaries of issues, articles and advertisements would have
at least been common. Two factors that you didn't mention that would impact on the
DTD design were the amount the client wanted to pay and their perceived
requirements of the data. Many magazines can be inexpensively marked up in HTML,
but of course the reusability factor is almost negligible.

> Most government- and industry-sponsored DTDs were designed by committees,
> and are nightmares of mediocrity, DocBook being a prime example.

I think DocBook was actually designed as an uberDTD, capable of representing almost
any type of information. I don't deny that it's a nightmare, but more because if
you make a DTD generic enough, you may as well just be using a word processor.

> Being able to construct a brick wall doesn't mean you're an architect. And
> although there are schools of Architecture, there are no schools (or even
> books) on the subject of DTD/EDD design. The 500+ page FM+SGML Developer's
> Guide tells you how to build an EDD, but not how to design one.

'Developing SGML DTDs' by Eve Maler and Jeanne El Andaloussi (ISBN 0-13-309881-8)
is pretty well regarded for DTD design, but I agree that there is a difference
between DTD and EDD design and that there is little information on EDD design.

> I'd build an EDD
> for some purpose, then I'd test it in the only way that works, namely using
> the EDD to create real documents. Then, I'd add to the EDD the things I
> realized were missing, and fix the things that weren't working the way I
> thought they would, and tested it again. It's a highly iterative process,
> even after you've acquired mastery of the toolset.

No question - iterative development is a must. There is always that point though
when you put the structure into production. Having done millions of pages of
conversion to SGML over the years, we assume that DTD changes will cease as soon as
the last page has been converted, so the iterative process carries on right through
the markup project. This is less likely to be an issue when creating new data than
converting legacy, but it can still crop up.

> 1. No one has written a tutorial on FM+SGML EDD design, and it's unlikely
> anyone ever will.

I think that part of the reason relates to the idiosynchrasies of datasets, don't
you? How could you make a recommendation about whether to handle a slight variation
(such as a different indent) in the EDD or create a new paragraph format in the
template without having some knowledge of how often the variation occurred, for
example?

> 3. After you've printed the Developer's Guide, read it. If you don't
> understand something, keep plugging at it until you do (understand it that is).
>
> 4. When you feel you understand enough to get started on building an EDD,
> try your hand at it. Then take your designer's hat off, put on your writer's
> hat, and flog the hell out of your EDD while creating real documents. Then
> go back to the EDD, fix the things you learned didn't work, add things that
> were missing, and test it again. Repeat until you're satisfied with the result.
>
> 5. Keep practicing, keep learning, and keep thinking about the proper design
> of structure and formatting. Eventually, if you keep at it long enough and
> diligently enough, some day you might be able to say: "I think I'm beginning
> to understand what it is that I'm doing".

All very true, and good advice. Just when you start to get it, XML will get full
support and throw you back into the quicksand. My bold New Year's predictions are
for full XML support, import and export XSLT support to replace read/write rules
and the addition of schemas to the family of files that currently comprise an
application. This is not based on anything that Adobe have said and I reserve the
right to reassign which new year I'm referring to...


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **