Re: There is a meaning, but it's not in the data alone
"Rick Jelliffe" <ricko@a...> writes: > So I certainly buy that the AF approach of a schema > language for expressing patterns that underly the > explicit markup is good. However, I think now that > we have a similar thing expressable using XML Schemas > (in a form apparantly amenable to OO programmers) and > with Schematron (in a form amenable to most people > AFAICT), I cannot imagine that AF per se has much of > a life. Archectural Forms has lost the battle but has > won the war. Please understand that I understand the difference between the battle and the war. Personally, I don't care about the battle; that's just syntax. I'm insisting that the war is *not* yet won, because the most basic lesson of the "architectural forms" paradigm has yet to be learned. The war is about the balance of power between information owners and information systems. Right now, the information systems provided by the largest software vendors have pretty much absolute control. That's bad for human productivity, cultural diversity, and the freedom of Adam Smith's "invisible hand" to operate in the best interests of human society. If we focus on that balance of power, rather than on comparing sets of fiddly little technical features and details, the work of the XML community will have much more meaning and effect. I keep bringing up AFs only in order to draw your (estimable!) attention to that balance of power, and to the need for a platform that will permit a mix-and-match semantic engine software market to thrive. AFs may be suboptimal for this purpose, but they are far ahead of anything else currently available. They indicate a direction for further work. (Rick, I simply could not resist the many pieces of Newcomb-bait in your letter. The words that these have elicited from me are attached below as a post script.) -- Steve Steven R. Newcomb, Consultant srn@c... voice: +1 972 359 8160 fax: +1 972 359 0270 1527 Northaven Drive Allen, Texas 75002-1648 USA P.S. "Rick Jelliffe" <ricko@a...> writes: > I think Archictural Forms failed to thrive for several reasons: > 1) it went against the dominant need of the mid-90s, which was for > minimal SGML to get smaller, not larger. XML, with its welter of add-ons, has now become more complex than SGML+HyTime. It's also terribly inconsistent with itself. SGML+HyTime is consistent, smaller, works better, is more powerful, and derives its power from its simplicity and full, well-balanced integration of all the basic concepts and structures for information management. The real reason for the lack of recognition that SGML+HyTime has received is that nobody is spending any money to defend the interests of everyman. The interests of everyman, and especially everyman's need to *manage* (rather than merely *publish*) information, is what SGML+HyTime is designed to serve. Meanwhile, the most basic engineering values (modularity and minimality) are routinely violated in XML-land. However, as long as XML 1.0 remains unsullied and dominant, the situation is recoverable. James Clark's award acceptance speech at XML 2001 included the sentence, "It's time to stab SGML in the back." I think this is premature. SGML+HyTime is still able to help pull XML out of the ditch that it's in; it's a gold mine of finely-balanced doctrines and ideas that will be useful whenever we decide to get serious about pulling XML out of the quagmire of confusion into which it has fallen. We should wait until XML is out of the ditch, and *then* stab SGML+HyTime in the back, if we still want to. To stab SGML+HyTime in the back before we are out of the ditch only serves the interests of those who want to keep XML in the ditch as long as possible. At the risk of being labeled a reactionary or a heretic, I must say that I think it's a big mistake to abandon DTDs -- at least for now. James Clark says, "DTDs are just a mess." Well, OK, I agree with him, there. But this is like saying, "Government by democracy is a mess." The problem is that there is, as yet, no alternative yet that's workable, popular, and widely available. If DTDs are abandoned, the abandoners will face abandonment by an awful lot of big information owners. > 2) it was put out as part of HyTime, and so its > message was diluted or buried This was inherently unavoidable. Indeed, XLink was forced to partially reinvent the idea of architectural forms in order to allow itself to exist. HyTime faced the same problem, except that architectural forms hadn't already been invented. So, they were invented as part of HyTime. > 3) it is still grammar- or tree-based, and so did not adequately address > the biggest lack of DTDs: non-regular constraints > (just as SGML's LINK feature was inadequately powerful to be much use) I dispute this claim. True, the architectural forms paradigm is grammar-based and tree-based. But it's not true that it doesn't address the problem of non-regular constraints. On the contrary! It provides a platform on which re-usable engine software can find a market. Such software can do anything that needs to be done. There is a subtle but important distinction between "DTD" and "information architecture". A DTD merely expresses a set of syntactic constraints on the interchange form of an information set. An "information architecture" is comprised of an information set (a set of semantics and semantic constraints), and a syntax for interchanging those semantics. A DTD is only a partial (and only a partially rigorous) expression of such a syntax. (And the DTD formalism is just one possible formalism. The architectural forms paradigm is not wedded to DTDs. Only the current implementations of it are wedded to DTDs. That could change, and I hope it will.) It all boils down to the fact that, for XML Namespaces, the names are the central thing. For architectural forms, the semantics are the central thing, and interchanging semantics is regarded as the whole purpose of XML. (This is why I was baffled by Simon's remark that he prefers to avoid semantic issues. When you take away the semantics that XML is used to interchange, XML has no purpose.) > 4) as species of transformation language, it is not powerful enough. The AF paradigm is neither intended nor designed to be a general transformation tool. Comparisons with transformation tools are misleading and irrelevant. True, the architectural forms paradigm can be considered to be a way of baking a single, very specific, very rigorous class of "transformation" into the source data itself. But in AFs, the source data describes its own "transformation". If the "transformation" provided by the architectural forms paradigm were not so limited, it would not meet the requirement that it provide a rigorous basis for information interchange, while distributing the authority to embellish, enhance, and mix with other information architectures. > 5) it invented its own non-SGML dialect with a meta-DTD containing > <!ADFR ...>, a new particle #ALL, > and new parameters on the SGML Declaration. (a) None of these convenience features are necessary to the operation of the paradigm. Bringing them up here only muddies the water. (b) Calling these convenience features "non-SGML" is misleading. The relevant ISO standard, which is a member of the SGML family of standards, calls them "SGML Extended Facilities". If that doesn't make them "SGML", what, in your mind, would? > However, architectural forms have not died: in fact they live > on through W3C XML Schemas. That's simply not true, Rick. XML Schemas do not support *multiple* inheritance. Under XML Schemas, there is no way that a single element can describe itself as being interpretable and validatable in various different ways in various processing contexts. In XML Schemas, the document author/maintainer/owner is *not* in control of the markup. A single targeted processing context is in control of the markup. A single document cannot work in multiple targeted processing contexts. > It allows you to specify an abstract grammar in which > gaps are allowed in content models for elements > (e.g. from other namespaces) and which (through > subsitution groups, etc) you can specify that the > particular names in a document are aliases for some > other names (or types), and which lets you augment > the information set with other attribute values. Yes, these are features that XML Schemas have in common with the architectural forms paradigm. So what? The basic requirements that I've outlined here are not met by XML Schemas. > Even Schematron has a role attribute, which could be > used to augment an information set for the benefit of > downstream processes. I think the path approach is > easier to figure out and more powerful than the > meta-grammer approach of AFs. I don't think so. I'll be convinced if you can show how, with your approach, a single element can describe how it can be validated and processed in multiple processing contexts, each with its own understanding of the valid context(s) and content(s) of that element. - 30 -
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