[
Lists Home |
Date Index |
Thread Index
]
"Rick Jelliffe" <ricko@allette.com.au> 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@coolheads.com
voice: +1 972 359 8160
fax: +1 972 359 0270
1527 Northaven Drive
Allen, Texas 75002-1648 USA
P.S.
"Rick Jelliffe" <ricko@allette.com.au> 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 -
|
