Re: [xml-dev] A question of necessity

[Steve Newcomb <srn@coolheads.com>]

On 04/23/2016 10:18 AM, Dave Pawson wrote:

Can [HyTime] A[rchitectual] F[orm]'s (or some variant) facilitate what a transform does with 2,
possibly 3 namespaces?

In think so, in at least one important sense, namely that when unexpected things happen (when information interchange fails), you'd be much better able to point the finger of blame somewhere specific, because the failure would have to be either in somebody's underspecified schema(s), or in somebody's failure to conform to the schema(s) to which conformance has been claimed.  (In SGML land, "...required to have been claimed".)

In my personal (and fairly unpopular) view, pointing the finger of blame for communications failures was always what SGML was all about, and the single most important thing that XML got wrong was to remove the pointability of the finger of blame.  Why even mention a "namespace" if it doesn't *actually* constrain the structure and content of the data?  How does such an annotation make the maintenance of a complex application of the named information set more practical in a globalized, decentralized, constantly-disrupting, rapidly evolving economy?  (Roger Costello's recent note about the economy's lack of effective provision for change is relevant here.)

Another thing XML got wrong (in my personal and unpopular view) was its failure to provide for ad-hoc, user-defined hierarchies of inheritance of structural constraints, all of which, at every level of inheritance, would allow the finger of blame to be pointable whenever applications (such as transforms) fail to support reliable, accurate information interchange.  This is the area where the HyTime Architectural Forms idea shines, and it's a very simple idea, really.  Here it is:

The generic identifier (aka the "element type name", the "tag") of an element is nothing more or less than the value of the one-and-only nameless attribute.  Historically, it has been used to specify the applicable constraints on its other attributes and on its content, but there is no fundamental reason why it has to be specially privileged over any other attributes in that respect.  Lots of attributes can fulfill that function simultaneously.  In fact, there can be as many constraint sets as there are attributes -- and many more if the constraint sets themselves are inheritable by other constraint sets. 

In AF jargon, a constraint set is called an "architecture".  HyTime provides a familiar syntax, called "meta-DTDs", for specifying the inheritable syntactic constraints of any given architecture.  Every existing DTD can be regarded and directly (and trivially) used as a meta-DTD.  HyTime itself is an example of an architecture, the syntactic constraints of which are expressed in the "HyTime meta-DTD".

There you have it: AFs in a nutshell.  If you can grasp the idea, you can readily grasp the comparative weaknesses and infelicities of colonized names, at least in the context of global information interchange.  You can also figure out why I believe that HyTime is beautiful to those who want global information interchange to thrive, and that it's dangerously subversive, and perhaps even blasphemous, to those who feel that successful global competition necessarily requires an anti-modular, monopolistic attitude towards the expression and interchange of information, and to the development of software that exploits such information.

Personally I think it's in the public interest:

to let millions of flowers bloom,

to support the ever-growing complexity of human semantics and human affairs, and

to decentralize control over what can be said and how it can be said,

while yet enabling ever-better information interchange.  So, I still like HyTime very much.  Even in exile and in rags, she looks as beautiful as ever to me.


Steve Newcomb