Re: [FrameSGML] Structured Document Design for XML or SGML

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Dan Emory wrote:

> Certainly the SGML standard does not dictate any kind of element naming
> conventions (other than length and permitted characters), nor does it limit
> in any way how attributes should be used. The purists have tried to
> impose another layer on top of the standard that requires element names
> to always convey content and content only, and forbids the inclusion of
> formatting information in any form whether it be in element names or
> attributes. They claim that structure must consist solely of a hierarchy
> of content-named elements, and that element context is always sufficient
> to describe formatting.

Rubbish. Who are these mythical purists and why have I not met them in my ten years
in the SGML market? You will routinely find a couple of formatting elements in DTDs
- for starters, tables are nothing if not formatting. I have occasionally built
hierarchical models to represent data that will be rendered on paper as a table, but
99 percent of the time I use the CALS model. Also, show me a decent sized DTD for
non-field-like data and I'll show you an Emph element - this stuff happens all the
time.

I think of structure as something that you layer over a formatted document. A
formatted document contains information that makes sense to one type of processor (a
person), but almost none to another (a computer). By naming certain aspects of the
document, the computer can make sense out of it, enhancing the experience for the
carbon-based processor as well, by presenting subsets or other variations. It's true
that not everything needs to be named - that's why you typically don't see elements
such as noun, verb, vowel and consonant in DTDs. For the same reason, most people
might use an emph element in place of an ExpressionOfGreatSurprise element.

> If formatting attributes are forbidden, then any style sheet (or EDD) for
> formatting
> SGML document instances must rely solely on element context. That
> means the original developer of the DTD has predetermined for all time
> what formatting variations are possible, because there are no
> author-specified "hooks" that can be used by the style sheet to reflect
> the author's vision by transcending context when the author thinks
> there is a need to do so.

This isn't restricted to structured documents - what's the difference between
providing a DTD and providing a Word template and locking off changes? Besides, I
doubt if many DTD creators could care less what the document looks like when the
author creates it, as long as the underlying structure is correct. Finally, the
phrases "for all time" and "DTD" are mutually exclusive. As data requirements
change, so do DTDs. Any system that is flexible enough to cope with any sort of
change probably doesn't do a great job of collecting data in a useful form.


--
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.   **