Cart
[Home] [By Thread] [By Date] [Recent Entries]
From: Murali Mani <mani@C...> > 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
|
