[
Lists Home |
Date Index |
Thread Index
]
[Simon St.Laurent]
> Recent discussions of HLink here and on www-tag have made me reconsider
> how much value there can really be in generic technologies.
>
> XML is generic markup, capable of representing pretty much any ordered
> and hierarchical content. (Applications can throw away the order if
> they choose.) Labeled structures are useful.
>
Let's look for a moment at the world of hardware, such as threaded fasteners
(including nuts and bolts) as an example. There are a number of specs out
there, and a large number of specialized designs with their own specs. But
there are some very broad ones. Generally they cover a broad family. For
example, the thread angle and percentage thread fill would be specified
along with some words on tolerances, finishes, and sometimes process (e.g.,
if you use a cold-forming technique then you have to need certain additional
specific requirements).
In many cases there are specialized specs that spell out details that were
not specified in the family spec.
This system has led to pretty good interoperability, but notice that you
cannot expect to mix a 1/4-20 screw with a 3/8-28 nut and expect them to
interoperate. Nor will US English-unit threads usually interoperate with
European metric threaded fasteners.
Now take another type of hardware, say, threaded connectors for electronic
cables. Almost certainly, a family specification for connectors will want
to specify a standard thread that has already been designed elsewhere for
threaded fasteners. This way, standard machine tools can cut them and
standard test gauges can check them. Only if this will not give acceptable
connectors would the developers depart from the standard thread designs.
These connectors will not interoperate with nuts in a hardware store, but
they will interoperate with each other and also with the design and
fabrication tools that are needed to make and test them. These are
enormous benefits.
The standards have evolved as a compromise between good strengh and
performance on the one hand, and low cost of manufacture on the other
(generally, this means allowing large tolerances and a variety of forming
methods). If I need special properties, like much closer tolerances or
special heat treating, I will still try to use the existing specification as
a starting point and tighten it up. That way, I get the benefit of years of
design experience and also manufacturing capability.
Is there a lesson here? Probably many. One is Len's repeated point, that
there are many forms and levels of interoperability and they may need
different approaches. Another is that general specs almost always need
additional detailed ones to adapt them to the task at hand. In the markup
world, these might correspond to profiles, or to specific language specs.
Another is that general specs are very useful, even though they may not suit
every need.
To make effective use of the generic/specialized spec pattern, a lot of work
has to go into getting a good balance so that the generic spec does not
allow just anything (else it would be useless), and yet so the specialized
specs do not need to violate the generic one.
Obviously, xml is a very generic spec (OK, Rec). I think that the pattern
of specialization into languages (say, MathML) fits the pattern described
above pretty well, and the approach has been very successful. Namespaces
alter the generic pattern but are still pretty generic. It is like
tightening the tolerances on screws. Most screws will still work, but a few
may not.
Where do the really controversial specs that w have been discussion fit into
this picture? Say, xlink/hlink, XML Schemas, architectural forms. That is
not too clear to me. The fact that most of them do not fit the pattern
well could be taken as a warning sign. Namespaces fit the pattern well but
of course they could still turn out in practice to be an undesirable
solution.
What we need to avoid is a clash of generic specs that are at about the same
level of generality. Thus, xpath/xslt 1.0 is clearly a specialization of
the generic, and have been widely accepted. But the 2.0 versions appear to
be mixing in a new generic spec (XML Schemas and their types) and many in
essence (I think) perceive a collision of the generics, so there is a lot
more distress about the new versions.
So we need to get a lot smarter about how specialized specs should work with
generic ones, when new generic ones are needed, and how the new ones should
interact with or restrict the old ones.
OK, that is already too much. Someone else pick up this ball and run with
it, please.
Cheers,
Tom P
|
