OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Why do you share XML?

Why do you always seem to ignore XML as a mark up rather than a data language?

From: "Costello, Roger L." <costello@mitre.org>
Date: Thursday, 1 October 2015 20:21
To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Subject: [xml-dev] Why do you share XML?

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.


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)?



Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. OUP does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of OUP. If this email has come to you in error, please delete it, along with any attachments. Please note that OUP may intercept incoming and outgoing email communications.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS