Re: [xml-dev] W3C Schema: Resistance is Futile, says Don Box

["W. E. Perry" <wperry@fiduciary.com>]

  [I don't think that your posting made it to xml-dev]

John F Schlesinger wrote:

> Walter wrote (in reply to John Cowan):
> "> Would you balk at my annotating the measurement "one inch" (measured
> > in 2002, to be
> > precise) with "2.54 cm", given that one inch is *defined* since 1958
> as 2.54 cm
> > exactly?
>
> That is not a nominal 'definition' but a mapping of commensuration
> between the results achieved by the application of appropriate process
> in the case of each unit of measurement."
>
> Well, I'm finding it increasingly difficult to understand what Walter is
> saying, but I have to agree (as a one-time physicist) with John. Since the
> inch was defined in terms of the centimeter, and the standard yard was
> thrown away (literally, the inch was defined by a piece of metal in a
> temperature-controlled lab), there is no definition of an inch except as a
> certain number of centimeters. So this is a nominal definition isn't it?

No, it is a specification of process by which particular semantics ('in
inches') might be elaborated from a value instantiated with the common
semantics of centimeters.

Items of the bare syntax of an XML instance must be instantiated in a form
which elaborates particular semantics before they can be operated upon by
process, or indeed understood in the most basic sense. The lexical
representation carries no standard semantics sufficient for comprehension by
process. As Mike Champion noted earlier, "there is a lot of territory
between helplessly dealing with <date>June 11, 2002</date> as a string that
requires human intervention to process, and drinking the Schema koolaid in
order to automatically bind it to a Date object." The problem that I see is
that only a tiny minority appreciate how much of that territory must be
covered every time semantics sufficient for processing are elaborated from a
lexical item. Many who are not drinking the Schema koolaid still presume
some standard semantics which simply are not there in the lexical instance.
Those semantics must be elaborated by process on each occasion; there is
always a choice of processes; and the instance itself, being a lexical
entity, does not tell us which choice to make.

I believe that I have an advantage in understanding this difference between
the syntax of an instance item and the semantics of its every usage because
I have seen an analogous rise of understanding played out in the field of
philology on the nature of oral poetry. It is still the practice in the XML
world to elide, and therefore fail to appreciate, too many of the ultimately
irreducible steps between lexical instance and processable semantics. It is
salutary that an unnuanced and overreaching Schema specification has raised
sufficient alarm that XML practitioners are now reexamining and discovering
the gradations along the route from instance to object. I take opportunities
to point out cases where--and which I hope will illustrate that--there are
steps along that route which cannot be elided without consequences which
will bring many of us back once again to reexamine the route and refactor
again the discrete steps along it.

John Cowan's earlier example of
Julius Caesar was assassinated on <date gDate="-43-03-13">the ides of March,
710 A.U.C.</date>
was irresistible to me because it conflated in markup lexical items which
offered choices of processing that would inevitably result in conflict and
undecidability. Processing AUC in the most usual manner proceeds one
direction in time with this instance and yields one result. Processing gDate
in its most usual manner proceeds a different direction in time and yields a
different result. Meanwhile the markup as given appears to annotate element
content to be processed in one manner with an attribute assertion to be
processed in a different manner and to yield an apparently incompatible
result. And, that attribute assertion when processed in a general, and most
common, manner appears to elaborate the semantics that those incompatible
results be considered the same thing. Because of all of this, I thought the
example could hardly be improved upon to illustrate the dangers of jumping
to a conclusion in semantics  ('these dates are the same') without doing the
necessary detail work of processing to get there, particularly when the
pitfalls along the way in processing are likely to keep us from reaching any
such conclusion.

Respectfully,

Walter Perry