Lists Home |
Date Index |
W. E. Perry scripsit:
> 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.
On this argument you might as well go ahead and commit yourself to the
notion that Cicero and Tully are not the same fellow, the one whose
ancestor had a nose that looked like a chickpea and was the greatest of
Roman orators. After all, we derive the name "Cicero" from his cognomen,
and the name "Tully" (which is less well known today, but was dominant
in pre-modern times) from an anglicization of his agnomen.
(I note that you have craftily not denied that you hold this position.)
> 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
I think this is undeniable, and in fact obvious. If you receive text in
French, and you know no French, you aren't going to be able to do much.
You can perform certain lexical-level tasks, like counting the words
(though even that will not work if the text is in Thai, or (for different
reasons) in Chinese).
> 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."
We'll hope that this koolaid is not of the Jim Jones variety! :-)
> 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.
This, however, is equivalent to the claim that when you and I talk F2F,
your English is just as incomprehensible to me as someone else's French
(I have no French) by reason of its different phonology. It just isn't;
I adjusted once and for all to how Grits talk, and now I have no problem
with it (I suppose the occasional griticism can still stump me, but
I doubt it after twenty years living with a Tar-Heel). (Apologies
to the international audience for these localisms.)
> 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.
No more it does. But we can have sustained agreements that carry us over
particular humps (not every possible hump, just particular ones), just
as I agree to map the vowels of your dialect into the ones I use, and
in fact do so as quite a low-level process. Otherwise there would simply be
no such thing as learning a foreign language, and all communications
whatsoever would be impossible.
> 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
This "inevitably" is a cheque you just haven't cashed. I say that, in fact,
there was a single day in history which can be labeled in a variety of
ways, according to the Gregorian, Julian Christian, Julian A.U.C., or
for that matter according to the reckoning of the Seleucid Empire, and
that these systems are in fact mutually interconvertable exactly, just
as inches and centimeters are. The difference from the latter case
is that the interconvertibility is only good to days and not to smaller
units, because of lack of precision about timezones, whereas inches
can be converted to cm with precision based on the precision of the
input measurement, just as you can convert francs to euros (between
1999 and 2001) arbitrarily precisely.
> 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.
In fact, neither specifies any *direction* in time, but rather an
*interval* of time.
> 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
Where's the incompatibility? The *actual* incompatibility,
not some generalized version of it ("all generalizations are false").
I could tell you that a German document dated "1 mai 1984" *might* not
be dated May 1, 1984, but anyone who knows any German would scout this
claim; those dates are interconvertible in fact. Finding a French
translation for "joke" might be a tad harder.
> 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.
What pitfalls? I *have* reached that conclusion, and there is plenty of
normative evidence to back me up here. If you don't believe that
Cicero is Tully (in fact; say you think that Tully is Quintilian),
I can triangulate by pointing to one and the same work which is
here attributed to Cicero, there to Tully; but I can't *prove* it.
You can always explain away any amount of evidence, but there is a price.
John Cowan <firstname.lastname@example.org> http://www.reutershealth.com
I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_