Re: [xml-dev] In converting XML instance A to XML instance B, thisproper

[Steve Newcomb <srn@coolheads.com>]

Semantics are in the mind of the author, and they are in the mind of the
recipient.  They are never in data, no matter how encoded.
Moreover, the only realities that matter are the ones in our heads,
because those are the only ones upon which we can act.

Communication is possible only because we believe it is possible.  We
believe it happens only because we have believed it long enough to
accumulate sufficient context with our correspondents to confirm us in
our belief.  It's a matter of preponderance of evidence.
Disappointments -- i.e., communications failures -- are inevitable.

If a commercial airplane is intended to land at Logan Airport, and then
fails to do so, we may be sure that the finger of blame for that failure
will eventually be pointed more or less accurately, even if the task of
pointing it requires stupendous effort.  In order to minimize the effort
involved, many systems are already in place, each of which is designed
to allow some set of responsibilities to be assigned and accepted,
thereby to make each step in the process of flying to Logan auditable.

I think your question, Roger, is not about air travel, but rather about
human communications in the general case, and I think there's a better
way to ask it:

"When communication is known to have failed, how do we minimize the
effort involved in assigning blame for the failure in such a way as to
prevent future failure(s)?"

Parenthetically, I feel I must mention, at least in this xml-dev
context, the fact that same question was uppermost the minds of those
who insisted, many years ago, that every SGML document must have a DTD.
 That was no misfeature.  It allowed the finger of blame to be more
easily pointed, at least when communications failed on account of a
discrepancy between actual document structure and expected document
structure.  With respect to structure, at least, all of the following
questions became inarguably answerable:

* Did the transmission conform?

* Did the recipient's process work correctly?

* Should the transmitter have known better than to transmit?

* Should the recipient have known better than to accept the transmission?

What I want to say has little to do with the overall structure of a data
transmission.  But it *does* have to do with pointing the finger of
blame for communications failures.  And the very same question is still
exactly the right question:

"When communication is known to have failed, how do we minimize the
effort involved in assigning blame for the failure in such a way as to
prevent future failure(s)?"

In other words, how can we constrain or compel the *construction* of
transmissions (not necessarily their *structure*, but certainly their
*construction*) and how can we constrain or compel the *interpretation*
of transmissions thus constructed?

I think the answer must have to do with the sharing of context.  And I
still believe that topic mapping (see disclaimer and reference below) is
a good way to establish and interchange a "preponderance of evidence"
such that construction and interpretation can be sufficiently
constrained and compelled to reduce the number and severity of
communications failures, and to tweak those compulsions and constraints
in response to experience, thus to establish and maintain a *community*
that *communicates* reliably.

Disclaimer and Reference: My definition of "topic mapping" has little or
nothing to do with any of the popularizations of that term.  It's a
simple idea, but XML mavens may have too much baggage to get there in
one step.  This link:

http://www.coolheads.com/SRNPUBS/groveProgenitorOfTMs.txt

may be better for you, because it traces the historical development of
the idea from the perspective of the original Topic Maps standard, which
could not be understood in the absence of a fair appreciation of the
GROVE paradigm.  (It's a matter of record that it was *not* widely
understood.)

Perhaps the key point is that it's necessary to make an explicit
distinction between a syntactic construct, on the one hand, and its
semantic, on the other.  Reliable semantic interchange -- i.e.,
communication -- is always extremely difficult, but in the absence of
the discipline of making such a distinction, reliable semantic
interchange is unlikely if not downright impossible.  Even thinking
about a topic map document means holding two perspectives on it firmly
in your mind simultaneously: a graph of subjects of conversation, and an
interchangeable rhetoric for that graph, which is a corresponding graph
of syntactic (and/or object or virtual object) structures.  This takes
some rather unsettling self-training, perhaps because our brains are
designed to ignore the latter and "pay no attention to the man behind
the curtain."  The man behind the curtain is the rhetorician in the
room, and, like the Wizard of Oz, even *he* doesn't know how it works.

On 11/29/2013 10:09 AM, Costello, Roger L. wrote:
> Hi Folks,
> 
>  
> 
> This hex string is the EBCDIC encoding of the uppercase letter A:
> 
>  
> 
>                 C1
> 
>  
> 
> This hex string is the ASCII encoding of the uppercase letter A:
> 
>  
> 
>                 41
> 
>  
> 
> Suppose we create a tool that converts EBCDIC text to ASCII text. The
> main aspect of the conversion is that the input has a property called
> semantics – its “meaning” – which must be preserved by the process. For
> example, the conversion must preserve this semantics: “uppercase letter A.”
> 
>  
> 
> Next, consider this XML which expresses the location of Boston’s Logan
> airport, using an ICAO code:
> 
>  
> 
>                 <Airport>
> 
>                       <ICAO>KBOS</ICAO>
> 
>                 </Airport>
> 
>  
> 
> This XML expresses the location of Boston’s Logan airport, using
> latitude/longitude:
> 
>  
> 
>                 <Airport>
> 
>                       <Latitude>42.3631° N</Latitude>
> 
>                       <Longitude>71.0064° W</Longitude>
> 
>                 </Airport>
> 
>  
> 
> Suppose we create a tool that converts ICAO locations to
> latitude/longitude locations. The main aspect of the conversion is that
> the input has a property called semantics – its “meaning” – which must
> be preserved by the process. For example, the conversion must preserve
> this semantics: “location of Boston’s Logan airport.”
> 
>  
> 
> But wait! Haven’t we stated that XML doesn’t have semantics? If XML
> doesn’t have semantics, how can a conversion process preserve semantics?
> 
>  
> 
> I’m confused.
> 
>  
> 
> Question: An XML instance document has semantics:
> 
>  
> 
> (a)    Yes
> 
> (b)   No
> 
>  
> 
> /Roger
> 
>  
> 
>  
> 
>  
>