Three misconceptions about ISO standards: what we can learn from hexalobular internal driving features

by Rick Jelliffe

I have been hearing a lot of fine sentiments about ISO standards recently. Is a high bar being drawn that does not reflect established practice objectively evidenced by the catalog of ISO standards?

There can only be one ISO standard for any application area

Oh yeah? What about ISO FORTRAN, ISO PASCAL, ISO Eiffel, ISO Common LISP, ISO C, ISO BASIC, ISO ADA, ISO C++, ISO C#, ISO EcmaScript, and so on? These are all programming languages, with enormous overlap in what they can be used for. What about ISO DTD, ISO RELAX NG and ISO Schematron? These are schema languages, again with enormous overlap in what they can be used for. What about ISO POSIX and ISO Linux Standard Base? What about (Ecma sponsored) ISO9660 disk format and (Ecma sponsored) ISO13346 UDF disk format?

ISO Standards must be made by combining the best of all worlds, and cannot rubberstamp a technology that came from a single vendor

Oh yeah? What about ISO 10664 Hexalobular internal driving feature for bolts and screws - Torx screw head? What about ISO PDF, ISO C#? What about (JIS sponsored) ISO QR Codes? ("QR Code is open in the sense that the specification of QR Code is disclosed and that the patent right owned by Denso Wave is not exercised.")

In an ISO standard, all elements should be supported by all application for interoperability

Oh yeah? What about ISO ODF s1.6 There are no rules regarding the elements and attributes that actually have to be supported by conforming applications?


4 Comments

len
2007-08-08 09:49:29
The same reply I gave Bob given yet another statement that we can come down to one family of related standards:


It sounds good but is IME is tough to actually do. The reason is the dreaded S-word combined with locale. It is similar to the problem of creating a data dictionary from multiple sources. How many meanings do you have for "eventType" or "incident"?


Semantic Web notwithstanding, this is the reason that markup systems prevailed over a common object-oriented framework. At that point, some of us realized that the only application we could all share semi-reliably was the syntax parser, and then we didn't share that. We shared the syntax definition. Then we relentlessly moved on to the InfoSet. From abstraction to distraction, relentless unstoppable churn in the implementations make one-size-fits-all standard uncomfortable to wear and unprofitable to manufacture.


Remember GenCode. Remember Architectural Forms. Look at what you actually can share among markup element declarations and ask how many simply come down to "boxed thing" with a URI for the "thing".


And so on. Today we can share URIs for things in boxes but even that major victory came at the cost of URIs being shoehorned into every conceivable use regardless of it being a good fit for the function and form. Thus XML Namespaces.


Have at but this is not a windmill. It is a fleshy full-grown and eternal fire breathing dragon called complexity brought about by local force vector scaling. It is a property of existence in systems bound to local space and time somewhat like evil and dark matter. No circular orbits, no predictable 3-body systems, and all rivers have tributaries and estuaries. Not being able to grasp the meaning of that wastes more design time than any other single cause and is the source of a not insignificant amount of friction and energy lost to heat in human to human communications. The answer is continuous negotiations and protocols.


That is what you really want from ISO: transparent negotiations and unambiguous protocols with emphasis on the first because the second will wax and wane (humans-in-the-loop).

hAl
2007-08-09 04:29:47
These misconceptions are actually driven by a few opponents that have want to influence ISO national bodies and ISO ballot voting. They need arguments for ISO national bodies to vote no and present as many issues as possible as an issues that either cannot be solved in the current fasttracking procedure and/or as issues that are blocking for an approval vote.
Also ISO itself does not really help as I see this kind of information being spread as facts to ISO national bodies but on the other hand see ISO JCT1 that seem to keep very quiet.
len
2007-08-09 06:11:55
Issues to block, etc., are the game as played. That such tactics come into the game are a result of the very high stakes on the table. For MS, it is preserving access to an important lucrative market, governments. For IBM and Sun, it is breaking the hold MS has on office documents by denying them access to those markets. This is competition based on political maneuvering using issues de jure, the lust of the young for dragons to slay, and the tastes of the old for vendetta and schadenfreude. ISO is being used by both sides for local advantage. Neither side has clean hands in this bitter butter battle.


But as told, demogoguery only succeeds if there is a scintilla of truth at the core of the argument. Otherwise, FUD doesn't propagate by amplitude modulation although frequency modulation can make it believable (a half-truth repeated often in the right places). There are two bits of truth here:


1. Access to public documents is an important responsibility of government.
2. Complex formats coupled to proprietary frameworks create lock in at scale.


Couple these and the choice appears that a single format solution would solve both problems undoing the Chinese finger puzzle.


So one asks, is the lock-in real or FUD? Does either solution merit a mandate and would that really solve the problem for the lifecycle predicted?


Or is a different mandate required?

Rick Jelliffe
2007-08-09 06:38:10
hAl: I think ISO and National Bodies are normally set up to provide secretariat services and to be resources for committees, and are very loath to become active players, even if their procedures allowed it. They can probably think more clearly out of the fray, so while it is frustrating, it is rational and defensible.