|
Hi Folks, Why do you create XML instances and then share—communicate—the instances with others? I have been thinking about this and it seems to me there are two reasons, which I describe below. I am interested
in hearing your thoughts on this. Perhaps there are other reasons for why we share XML? Perhaps the description below is unclear and needs sharpening? Having a crystal-clear vision of why we share XML … well, that seems supremely important. Note: this discussion is focused exclusively on machine-to-machine sharing of XML instances:
It seems to me the fundamental reason we share XML is to either (a) direct or (b) enable
behaviors.
1. Sharing XML as a Means of Directing the Behavior of Machines When you share XML it because you want to dictate how other machines behave. You and the machines have agreed
a priori as to what the XML and its data means and what behavior the machines should exhibit upon receiving the XML. In a sense the XML is pushing buttons in the machines, causing them to behave in certain ways:
Example #1: The Internet Protocol (IP) header is an example of this. Each field in the IP header elicits a specific behavior in routers and gateways. The routers and gateways have agreed
a priori to behave in the desired manner. Example #2: The XSLT vocabulary is another example of this. The XSLT specification describes the behavior of machines (XSLT processors). Upon encountering, say, an
xsl:for-each element the XSLT processor must iterate through each sequence item. Douglas Comer defines "protocol" this way:
Protocol specifications define the syntactic and semantic rules for communication. They give the details of message formats, describe how a computer responds when a message arrives, and specify how a computer handles errors or other abnormal conditions.
Hey, this sounds exactly like what I've been describing. XML is a protocol specification.
2. Sharing XML as a way of Enabling Various Behaviors Perhaps you are
laissez faire about how machines should behave. You specify the meaning of the markup and of the data and leave it up to each machine that receives the XML to decide how to behave. Although each machine gets to choose how it behaves (i.e., what it does
with the markup and the data), it is not free to interpret the XML in its own way. The XML creator has defined what the markup and the data means, the machines must conform to that definition. So in this case the sharing of XML triggers a behavior but does
not dictate the exact behavior. XML is a collection of data that a community has determined to be sufficient and useful:
Example: An XML instance has an element, altitude, whose value is an integer. The data within the element must be interpreted as the number of feet above the ground. All machines that receive
the XML must interpret the <altitude> element in this way.
Comparison It seems to me that the second usage of XML (using XML to elicit various, unspecified behaviors) is harder, for these reasons:
(1) How do you know that the "collection of data" in the XML is complete, that there is sufficient information for machines to do something useful with it?
(2) Compliance testing is really hard. How can you be sure that all machines will interpret the data according to the semantics that you (the creator of the XML) specified? For instance, how
can you be sure that every machine will interpret the data within <altitude> as the height in feet above ground, and not the height in meters above ground, or perhaps the height in feet above mean sea level (MSL)? Comments? /Roger |
