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

[gkholman@CraneSoftwrights.com]

At 2013-11-29 15:09 +0000, Costello, Roger L. wrote:
> 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.”
No, the program has been instructed to interpret 
C1 as EBCDIC and to put out ASCII.  There is 
nothing about the hexadecimal value C1 that says 
it is the EBCDIC letter A.  I might just as well say "C1" is Á:

  http://www.fileformat.info/info/unicode/char/00c1/index.htm

> Next, consider this XML which expresses the 
> location of Boston’s Logan airport, using an ICAO code:
>
>                 <Airport>
>                       <ICAO>KBOS</ICAO>
>                 </Airport>
That label is pretty convincing in leading me to 
interpret the string as an airport code ... but 
it is just a labelled piece of text.

The label tells me how the sender intended the recipient to interpret it.

But what if I ask myself  "which airport codes 
are also FM radio stations?"  Then I'll get this answer:

  http://www.radio-locator.com/info/KBOS-FM

I chose to interpret the labeled airport code as 
an FM radio station's call letters, specifically 
because that was my purpose in interpreting the 
label ... I was asking myself "which airport 
codes are also FM ration station call letters?".

Just because the sender labels it an airport code 
doesn't mean I have to interpret it as an airport 
code ... though for interoperability it would 
help if I interpreted it as the sender intended.

> 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.
So the tool is interpreting the labeled content to be an airport code.  Fine.

> The main aspect of the conversion is that the 
> input has a property called semantics – its 
> “meaning” – which must be preserved by the process.
No ... the sender *wants* the recipient to 
interpret the labeled content as they intended.

> For example, the conversion must preserve this 
> semantics: “location of Boston’s Logan airport.”
No ... the conversion must choose to implement 
the semantics "Location of an airport by its code".

> But wait! Haven’t we stated that XML doesn’t have semantics?
Yes, numerous times, and I'm surprised you are bringing this up once again.

> If XML doesn’t have semantics, how can a 
> conversion process preserve semantics?
You just said it!  XML doesn't have semantics, 
the conversion process implements semantics.

Meaning is in the eye of the beholder.

> I’m confused.
I'm surprised you are asking this again.

> Question: An XML instance document has semantics:
>
> (a)    Yes
> (b)   No
In my opinion: (b)

I hope this helps.

. . . . . . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/ |
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |