Lists Home |
Date Index |
From: "Paul Prescod" <firstname.lastname@example.org>
> But is anyone using SGML features that were left out of XML? CONCUR,
> LINK, DATATAG, OMITTAG, RANK, SHORTTAG? I still use some for my personal
> projects but I don't encourage my customers to. If the only difference
> between SGML and XML in common usage is the empty-tag and processing
> instruction syntax then SGML survives but not in a sense that I find
> very meaningful.
Sure people are still using them :-) Because XML has not provided any extra
or equivalent functionality for people who need to mark pre-existing material up,
it has not made inroads into many of the traditional SGML markup shops.
XML has not really helped people who need to mark up pre-existing material, has it?
OMITTAG, SHORTTAG and SHORTREF (i.e. the optional features of SGML that
proved themselves useful) were all oriented to markup minimization. Terseness
is of minimal importance in XML.
One of the main characteristics of marking up is that the document-in-progress
is not a well-formed tree. So tree-based or WF-based tools are not the right tools for
the job. The need to reduce the number of operator keystrokes to a minimum without
requiring a large or ongoing GUI customization budget dictates that direct text
editing with markup minimization still provides a solution that is attractive
for productivity and agility.
After a document is marked up, and can be normalized into a nice
tree or XML document: then the new world of XML-branded technologies
(XSLT, XML content management systems, etc.) is great. SGML
users are richer by having available XML processing tools; but XML
users can be richer by using SGML for markup, where that is appropriate.
> Is SGML a thriving, growing technology separate from its XML incarnation?
Certainly not. But that is just as much because of anti-SGML FUD as
the virtues of XML. We are now hearing the corporate "tags are too
hard for users" mantra again, as if HTML had not disproved that thoroughly.
We have seen the "XML effect" in several cases now too: an SGML company
succumbs to the prospect of high sales, moves into "XML content
management", then fails.
Because XML makes content creation more difficult than SGML, it naturally
gravitates towards DBMS systems rather than starving for lack of input.
So XML becomes more and more a middleware-to-backend interchange
format, rather than having much to do with publishing or having content to
manage. As publishing becomes marginalized, we are seeing XML being
redeveloped to be primarily suitable for data interchange, with publishing/editing
requirements left forlornly at the door, like a faithful dog wet in the rain.
A sad image; get out your handkerchieves!
AFAICS, XML is no more thriving on the desktop than SGML ever was.
And, indeed, the marketing that XML is better than SGML for all uses may have
put on hold the spread of the complex document systems down from publishers
to the next tier of sophisticated users.
> SGML has achieved its success under the name XML.
It certainly has achieved its fame under the name XML! And rightly so.