Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: OPEN LETTER: Standards must stand on their own
 Don't know if I like the idea of multiple namespaces, but.. >James Robertson wrote: > > This has highlighted what I think is > an important point: > > "Standards must speak for themselves. > They must be clearly 'the right way' > to solve the problem. If they require > advocates, then they have failed." Any idea, whether you get beyond it or not, requires advocates. Few ideas which adapt existing technology or ways of working are accepted with a Duh slap, and a why didn't I think of that. What is required, as has been pointed out, is rationale in the face of honest differences. > If a standard is not well received on a list > like this, then what chance will they have > in the real world? There, if a standard is > not liked, it will be ignored. This would be > a terrible waste for all involved. You must have been in school when HTML was launched. The debates were real and vigorous. There are many reasons not to like a standard or an implementation. The proof and the acceptance is in the implementation. Even then, there may be better ideas but the market will rule. There have been some very lucid articles on ZD-Net and elsewhere as people have begun to understand that market rules do not tend to benefit the consumer. Sometimes, it is better to question the freebie, investigate the claims of originality and appropriateness, and understand tech before investing. That is just good sense. Waste is a fact of industry. > Standards should not be controversial. They > should not 'innovate'. They should solve a > problem the 'best way' based on the real > world experiences of all involved. Agree and disagree. There is plenty of literature that claims relational databases are all you need. I can cite from experience efforts to make PDF the sole accepted standard for digital documents in some domains. World experience is not sufficient. The acclaimed solution often depends on the local domain or politic. > If there is no experience to guide us in > an area, don't create a standard. Wait. > Experience will come ... No it won't. I agree standards should be created once products reach commodity status, but if you wait for experience you will only get a standard no one understands or understands why it should be standard. At some point, as the buzzard says to the next buzzard, "Patience my ass, I'm gonna kill me something." Science and standards depend on repeatable results. > With respect to the XHTML spec, it means > that it should go back to draft status, > and remain there until a solution presents > itself that is unarguably elegant, and > practical. Foolish. It should be argued over like meat in a wolves den. It is important. It should also be noted that wolves fight but also live in communal packs. They cannot choose to be wolves, and that is the difference here. This group can. > If this cannot be done now, don't release > the standard. If the world is not ready to > create a single defensible standard, then it's > not ready for a spec at all. And would not be ready for government if individuals did not choose to govern. You live under law or you don't. Civil disobedience is the alternative. It is, for the individual, sometimes the best alternative. In other words, if XHTML As Spec'd is unimplementable, don't implement it. Your choice. If others do and it works, then they made a better choice. This was the same choice made about HTML originally. There were better ideas and better systems. Care to roll back the clock to 1991 or stay in the fray? > In conclusion, I would like to draw parallels > with other standards bodies. The IETF, for example, > has a very good history with standards. Standards > such as HTTP 1.1 were released without much fanfare. > Everyone looked at it, admired it, and in due course > implemented it. All with very little argument or > discussion. Wrong. Running code and rough consensus. IETF defines working designs which have to be proved by implementation. Very practical. The difference is, the IETF is not a consortium. Anyone can sign up for the debate and get the details. The argument here is about W3C processes that result in decisions not justified by rationale. It creates an atmosphere of suspicion, mistrust, and fear. > Other bodies, such as the ISO, hold the other > position. People tend to look at their standards > and become frightened by their complexity. ISO > standards have a long history of not being used. Wrong. HTML is based on an ISO standard. ISO has a long history of responsibility, credibility, attention to detail and process, and a reputation for good product. There are many ISO standards in use every day, some good, some not as good. However, they have produced many standards and not all of them succeed. That could happen to XHTML but not for lack of interest. Again, XHTML is not a standard; it is a consortium-owned technology. It is the schema for an application. > So I say again: > > Standards must speak for themselves. No. Implementations must prove them. Markets can adopt the products. But people, individuals, speak for their work. That is the primary and most defensible argument in this long and yes, silly debate. len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
