Re: Way OT: Adam Smith and Software Markets

[Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>]

Samuel Tardieu <sam@rfc1149.net> wrote:
: For example, you cannot say whether
: 
:  <ul><li>List item<li>Second list item</ul>
: 
: is valid in SGML, it depends whether the grammar says that a <li>
: closes a preceeding <li> at the same level or not, and whether </ul>
: closes embedded <li> or not.

Yes, and if memory serves right, it also requires the SGML declaration in
addition to the DTD, for the parser to known whether or not
element type declarations may say something about tag
omission etc.

Still, XML, being a subset of SGML is not a novelty, which is what
I was trying to say; there is no new concept in it, *but* this doesn't
mean that it shouldn't have been that neglected in the first place :-)

: such as <br/>. This makes writing parser or transformers much much
: easier than their SGML counterpart. There, and only there, lies the
: big progress.

Yes, a progress for parser writers, but not necessarily for human
beings typing markup, or even for people coding of parsing event
handlers?  Computers  should work for humans. (Seems it's often
the other way round.) XML is very useful, but where.

From the perspective of a human, writing DTDs and writing
XML or SGML documents: Using both a sophisticated
validating XML-editor that hides the markup if I want to and two
other editors, wily and Emacs+XAE with SGML; sometimes using the latter is
much more productive, and I'm glad I can use SGML's minimization
features. The outcome is almost pure text; it is a pleasure for the
writer to place a </> end-tag instead of a lengthy </expressiveName>,
when this name is all too obvious from context.
XML can always be produced from SGML input.

And like Ada, SGML is not case sensitive, unless requested.

A similar comment applies to DTDs: writing these can in cases become
really tedious when only the XML subset is allowed; to give just one
example: when  the "and connector" & is disallowed, as it is in the XML
subset, and you want a content model for car choice like

 (color & motor & comfort),

this forces no order where none is needed. XML prohibits this ease of
specification. The absence of & is just introduced to make
the parser writer's life easier.  This is one reason why XML-DTD tools
or XML Schema tools are not only helpful, but they are much needed to
overcome the restrictions of XML in this case. Otherwise you would have to
write

 ((color, motor, comfort) |
  (color, comfort, motor) |
  (motor, comfort, color) |
  (motor, color, comfort) |
  (comfort, color, motor) |
  (comfort, motor, color ))

or similar for the exact same thing. So what can smart XML DTD tools 
do in this case? They can effectively retrofit SGML features onto XML.
:-)

So, from this perspective, the biggest progress is an opportunity
to sell unneded tools to overcome these XML-induced difficulties
(I'm exaggerating a lot, and actually XML is _so_ helpful in data
transport).

-- Georg