Re: Regarding the vote on XML Schema.

[Rick Jelliffe <ricko@allette.com.au>]

From: Murali Mani <mani@CS.UCLA.EDU>

> Also, I believe everyone appreciates the work done by all the
>concerned parties -- there are no winners or losers -- the goal is to move
>towards the best solution, and every approach, correct or wrong, is a
>forward step and adds to our knowledge and experience.

You still talk of a "correct" approach.  As I have been trying to say,
*that* is the root of the problem, not any particular decisions.  The
particulars are a trap, a gaudy disco-ball to hypnotise us and keep us away
from pluralistic, human-centred WWW.

Take the issue of ambigous or non-ambiguous content models, for example.
There is no way to come up with a "correct" solution to that: if one takes
one approach it opens up some doors and if one takes the other it opens
other doors.
And should one use longest-match or shortest match?

The first thing that any schema language spec should do is situate itself
within an explicit RDDL framework, since that is the closest we have to
modularization. And schema language communities should try to find out where
the limits of their approach is, to avoid party spirit, and to encourage
maximal use with other schema languages.

I don't see any difference in RELAX and TREX and XML Schemas in this,
frankly.  Do any of them start with the design goal of being pleasant for
non-experts, or of being easy to program using fixed-format non-nesting
forms, or of providing best error messages to users?  Do they start by
analysing what information people need or are capable of using, then trying
to figure out how to support this (no! the great "the GUI will fix all that
up" scam can be invoked.) Do they start with a coherent view of what data
model to support (e.g. the  "infinite annotatability" model I am trying to
push versus the 3rd normal form model that dominates of XML Schemas)?

No, they start by marginalizing human needs and deferring data models, which
leaves discussions to revolve around the evaluation of techniques against
largely mythological use-cases.  If the T-RELAX group at OASIS wants to be
really different to XML Schemas, they should abandon all discussions of
techniques until they first can put up a justification of what things are
important for humans to use.  (Or, if they are not interested in making
technology for humans, they can try to justify that too: fair enough.)

The brilliance of James Clark's programming and the habitual goodness of his
heart, the admirable determination and pioneering spirit of Murata-san (who
has selflessly had to work on so many projects such as MIME and the Japanese
profile of XML that divert him from his life's work), the institutionalized
humility of the XML Schemas WG who took an extra year to evaluate and
respond to community comments on XML Schemas despite _considerable_ economic
pressure to finish earlier, all these are inspirational, and I am the last
person to want to diminish them.

But when considering the actual schema language development process, if a
technology does not spring from considering human factors first, it becomes
part of the problem not the solution, to me.  Slogans such as "simplicity"
or "over-complexity" or "bad theory" mistake the goat for the cheese.  The
reason for plurality is not merely because there are lots of different
methods and we should be able to fit the best schema technology to the
problem at hand, but because humans have different capabilities.

So we don't get too airy-fairy, here are some examples:  what kind of
language would be most suited for people with limited eye-sight? what kind
of language would be most suited for people who have not studied computer
science?  what kind of language would be most suited for Okinawans?  what
kind of language would be most suited for people who need to annotate
existing documents?   What kind of schema language would be most suited for
the elderly?  And so on.

>I am not sure, but I think this probably cannot happen unless W3C honestly
>announces something close to the effect that it is studying the approaches
>by both the parties.

But didn't the formalization people recently say they were explicitly
adopting some RELAX or TREX ideas into MSL?

Murata-san was a member of the Schema WG, he presented his ideas as they
were formulated then, and they failed to win the day, for whatever reasons.
The idea, in TREX and others before it, that you should tie element and
attribute occurrences was also discussed (to what extent I don't know, it
happened before my time) under the guise of "co-occurrence constraints, and
again it failed to gain enough votes.  It is fair game to debate the merits
of these decisions, and to look at whose interests these decisions support,
or what kinds of documents are well supported by such decisions, but it is
not fair to say that the issues were ignored completely.

> But do we believe that the opposition to XML schema is merely
>the unanimity problem a difficult specification faces?

Yes. The difficulty is perhaps good, because by showing up that XML Schemas
1.0 is a pragmatic approach to solving certain problems based on the inputs
available in 1998/1999, it may disabuse people of snake-oil marketing.  How
do standards groups, committees, vendors groups, informal working groups and
so on operate?  By and large they start with some existing technologies and
prejudices and expertise and tastes and they work through some problem: the
tradeoffs they make are not scientific--they are not based on empirical
analysis of what problems people face.  Instead they usually retreat to the
world of ideas and abstractions, where they persue some fundamental ideas
considered "core" to the stakeholders.   Just because a language is small or
elegant does not necessarily make it more or less useful or expressive or
helpful to people.

>I am not sure whether I am answering Rick's question straight -- but which
>is a monolith -- RELAX or XML Schema?

Both, when espoused by puritans, universalists and other diversionists.

Cheers
Rick Jelliffe