At 03:16 PM Thursday 2/22/01, Sjoerd Visscher wrote:
>> Could you try writing a DTD for the Minimal-XML representation you
>> have in mind for (a small sample portion of) Kernel-E?
>
>Then I'd first have to learn to write DTDs, which I refuse.

>> While this is a sensible stance, a DTD to express such constraints
>> would be explosive.
>
>To me, DTDs are totally unimportant. That's because the format isn't
>Minimal XML. Minimal XML applications should only need to be able to
>read Minimal XML. [...]

I think this raises an important issue which needs to be settled before many
of your other points can be addressed.

A process such as SML-DEV gathers enthusiasts around common draft proposals
because each sees in the proposals their own reasons to be enthusiastic.
This leads to a diversity of goals, which can be great. Good standards
should serve a great variety of goals simultaneously, and I believe
Minimal-XML is well positioned in this regard. However, sometimes different
goals would pull standards in incompatible directions, in which case it is
better to split than to balkanize.

At the risk of alienating the group with my cynicism, I'd like to explain
why I am and am not enthusiastic about Minimal-XML. I know these goals
differ from many of yours, but I hope we find enough common ground to
proceed towards a mutually agreeable set of standards. (The following
expands on the intro text at http://www.smallstd.org/ .)

There are two very different kinds of technical work:

1) Purely exploratory idea work, in which one need not pay undue attention
to issues of compatibility, installed base, ability to leverage existing
tools and existing ways of thinking, and the marketing issue of *perception*
of compatibility.

2) Work done for the purpose of affecting the world, which requires engaging
with the world, which typically requires widespread adoption. During the
attempt at adoption, all of the above kinds of compatibility can exert bone
crushing pressures. At least it feels that way.

(These are actually two extremes of a spectrum. Often, hidden internal
mechanism can be more towards #1 while being embedded in a product more like
#2.)

In my career I've gained much by oscillating between these two modes. I
participated heavily in the design of the Joule language
http://www.agorics.com/joule.html which I personally prefer in almost all
ways to E. I'd much rather program in Joule that E. So why have I spent
the last four years of my life building and promoting E? Because I designed
E to be a vehicle in which the core ideas of Joule can have a chance at
seeing widespread adoption, at the cost of compromising many other ideas. In
exchange for these compromises I get instant reuse of the Java APIs, and
instant familiarity to programmers schooled in the C/C++/Java/Python/csh
syntactic tradition. E is an exercise at #2 in order to promote ideas
discovered by doing #1.

For me, the compelling analogy is: Lisp S-Expressions (or almost
equivalently, Prolog term trees) as #1, XML as the installed base to be
compatible with, and Minimal-XML as #2.

40+ years of symbolic programming have shown the power and simplicity of the
Lisp S-Expression, or almost equivalently, the Prolog term tree. However,
despite their long and proud history, neither has seen widespread adoption.
Then, recently, for reasons I cannot fathom, XML has taken over this niche
like a cancerous growth. The only good thing about XML, as far as I can
tell, is what it shares with S-Expressions. Unfortunately, it's about 100
times more complicated. (I don't think I'm exaggerating.)

Enter Minimal-XML. It throws out of XML essentially everything except the
good stuff -- the S-Expression-nature. The result is not much worse than
S-Expressions, and so is something one can stand. At the same time, *if* it
is defined so that a valid Minimal-XML document can also be a valid XML
document, it allows one to answer "yes" to the question "Is it compatible
with XML?". Often, to answer "no" to this question is fatal.

Even better, having answered "yes" to the first killer question, the
Minimal-XML standard allows us to resist the inevitable pressures to add all
sorts of other crap to our data, like Namespaces, that are somehow "thought"
to be good by people who see no need to think about the matter. When they
ask "But shouldn't you be using Namespaces too?", we can say "But that would
be incompatible with Minimal-XML, another standard to which we conform." To
them, more standards conformance is better, and so they will often accept
this answer without ever learning what Minimal-XML is.

So that's why I'd like to see Minimal-XML accept and ignore the DOCTYPE, and
why I'm interested in writing Schema that can be automatically translated to
readable DTDs. This allows me to write documents valid by both standards.

Although I know my reasons are much more cynical than many of yours, I'm
puzzled. If you're not interested in the ability to claim XML
compatibility, why are you interested in Minimal-XML? Why not use something
cleaner and simpler like S-Expressions?

In any case, if one of your goals is widespread adoption, please consider
whether my cynicism may be widely shared (I believe it is), and may
therefore be leveraged to gain this widespread adoption. You could offer
hope and rescue to people in a tough situation, and in the process
substantially puncture the momentum of bloated standards. Looked at this
way, it's no longer cynical, just virtuous.


Cheers,
--MarkM