[
Lists Home |
Date Index |
Thread Index
]
This may turn into an interesting thread.
Is this a fair assertion: few markup system
users will be productive unless a markup specialist
sets up the system for them? A lot about the
perception of markup is determined by the
tradeoffs this person is trained to make.
Given that assertion, what is the best markup
design that the specialist can produce to
get the highest productivity from the user?
What is the impact of the GUI chosen on the
design of the XML? (ideally, none, but this
implies costs).
Long ago and far away, we had the SGML Way.
Without getting into the details, it did not
always produce good answers for these questions
although it could ensure a well-annotated
document. Much of the slag laid at the feet
of SGML was the result of monolithic document
types, and insisting on the SGML Way over smart
and efficient markup designs for particular
applications. We tend to accept uncritically
certain myths, and I believe, for that reason,
repeat certain mistakes.
XML is supposed to be the culmination of the
shared experience of the SGML community.
Have we gotten any smarter?
Here are two possibly mutually exclusive
assertions I've encountered along The Way:
o Markup tags should be human readable
and understandable, using lower camel case.
o The length of a tagname does affect
message size and in network applications,
this can affect system performance.
Given a situation, either of these is true.
Given use of XSLT or other transformative
technologies, neither is exclusive.
len
From: David Megginson [mailto:david@megginson.com]
The real problem is that neither SGML nor XML is particularly easy for
authors to use and understand. In the data world, we can remove much
of the unfamiliarity by using input forms, but in the document world,
authors have to learn the whole new world-view of generic markup even
if they do have nice, GUI-based, WYSIWYMG editors to hide the pointy
brackets.
|
