[
Lists Home |
Date Index |
Thread Index
]
From: "Mike Champion" <mc@xegesis.org>
> Question: this was a much-touted advantage of SGML, but did/do off-the-shelf
> SGML processors (Epic, XMetal, SP, etc.) support this kind of thing? Or was it
> something that people wrote custom code to handle for every "little language"?
The three most popular SGML processors (SP, SGMLS, OmniMark) all support
short-references and minimization (the two go together, to allow infix delimiters
such as a^2 ) and it is widely used, for element values.
"SGML" and "XML" editors are very different animals: they typically parse the
SGML on opening, and present some kind of a tree view. So they are
really "infoset editors".
Shortrefs (+ minimization) are useful for:
- reducing the markup:data ratio (smaller file size, less typing, more screen area
dedicated to text)
- increasing the readability of the text (less fluff, or use familiar delimiter such
as blank lines as paragraph separators and inital tabs for list item starts)
- allowing easier import: an external entity could be a CVS resource, and
it is parsed into elements by the recipient rather than requiring the
sender to use XML
- increasing the recoverability of the text (in case of missing markup)
The QUASIWYG XML editors will typically try to provide different mechanisms
for the same outcome:
- turn off tags for more screen area
- provide simple stylesheets
- treat data conversion it as a server-side problem (hence the need for
query languages etc)
- prevent the user from making mistakes
So you could say that underlying the SGML/XML-as-text editor
and the SGML-XML-as-infoset editors are very different assumptions
about skills levels, maintenance, system architectures, content
management, work practises of operators, document sizes,
and the tasks involved in editing (e.g. entering new text or
marking up existing text.)
Cheers
Rick Jelliffe
Topologi Pty. Ltd.
|
