Re: Not using mixed content? Then don't use XML

This is the 'Talmudic' approach which I have tried to champion. I got into markup because by definition markup posits that anything to which it is applied is a 'text', the understanding of which will benefit from explication or exegesis. The converse of the Talmudic approach is the dogmatic, in markup as much as in theology. The dogmatic approach is realized in markup processing through an interface, which comes with the interchange contract or implicit guarantee that a message submitted to that interface will be accepted and processed in a known manner, provided that it conforms to the input schema governing that interface. The input validation schema is thus the gatekeeper for the process behind the interface:  it is the inquisitor which determines the suitability of any candidate text to engage the operation of a particular canonical process.

This dogmatic validation is the most rigid and brittle of connections between nodes. In the first place, it requires that any process which might participate in a pipeline of processes must condition its output to the expectations of the next process in the pipeline--which in turn requires that there *be* a fixed, known, 'next' process. That requirement violates two (I would say, *the* two) fundamental design principles:  First, the output of any process ought to be the best possible expression of the particular expertise of that process. This expectation of a process is what makes that process intrinsically valuable, and thereby desirable to include as a canonical process in a pipeline. Where the output of a process is constrained to the expectations of a particular user, the goal of the process is perverted from achieving the best outcome of its own understanding, into simple conformity to dogmatic expectations. This is the antithesis of a good design principle, and violates as well the second essential principle that design should be structural and conducive to its own meta-design:  Processes built to be each the best realization of a particular function should themselves then be re-combinable in new and unanticipated structures, in order best to answer previously unanticipated needs. The only way to respect these two fundamental design principles is to create each process without reference to what process is next in the pipeline, or how an output text is to be understood by its next consumer.

John has cleanly distinguished the prescriptive 'input validation' schema from the descriptive 'output validation' variety. There is also the fundamental difference that input validation is inherently and unavoidably intolerant:  a process is written to rigid expectations of the input on which it can operate. On the other hand, a descriptive schema accompanying a published, concrete text is but only a single understanding of that text's structure or use, or of the intent which motivates it. One descriptive schema does not preclude many more, each commenting upon the same text. It was my understanding 20 years ago that the 'Web' would for this very reason inevitably shift the paradigm of process design. URIs gave us unlimited named and addressable nodes, at each of which some 'text' might be published. That text was published as, effectively, the expression of what its named node *was*. That identity was purely ontological, not functional--but  clever processes could, and would, find various uses for the text published at a given node, conditioned in each case by differing understandings of that fixed and published text. A fundamental burden of process design is thus shifted by the Web paradigm from data publisher to data consumer. When we compromise on that shift, we lose the principal benefit which markup on the web--the two legs of our practice--have brought us.

From the high-flown to the utterly personal:  it was a real pleasure to see John on 3rd Street the other day (and to be free to have that opportunity). Simon's comments about me, and elaboration on them which I have received off-list, have done me extraordinary good, and I am most grateful. I will not be allowed to attend Balisage this year, but will expect to follow all of your presentations, with the greatest pleasure.

Gratefully and respectfully,

Walter Perry

Don't miss another message! Subscribe to this list today.

Email

First Name

Last Name

Company

Subscribe in XML format

RSS 2.0
Atom 0.3
Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.