[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
[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
|
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
|