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: The real world doesn't have an "other xyz", neither should yourXML

In my work, I've often preached that a Schema/DTD should model the business process.  When someone wants an "other" element or attribute value, it's almost always because the business process is ill defined, sometimes inadvertently, sometimes deliberately.  So long as no one expects very much from any machine processing of the value of an "other" element or attribute (other than recording the value, for example).  Yes, it's useless, but also probably harmless.

Still, it's a laudable goal, Roger.

Bruce B Cox
OCIO/AED/Software Architecture and Engineering Division

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: 2014 February 9, Sunday 09:27
To: xml-dev@lists.xml.org
Subject: The real world doesn't have an "other xyz", neither should your XML

Hi Folks,

I see many XML instances (and corresponding XML Schemas) with an "other" catchall element.

I wish to convince you that an "other" catchall element is contrary to one's objectives and should be avoided.

First, a quote from the book, "Principles of Program Design" (Jackson Design Methodology):

	The structure of a program must be
	based on the structures of all the data
	it processes.

A corollary to that is:

	Data should model the real world.

So there is this deep connection:

	real world --> data model --> program structure

In the real world there is no "other" component: When was the last time you drove an "other car" or purchased an "other vegetable"?

So it is wrong to create a data model for a nonexistent real world entity. Likewise it is wrong to write a program component for "other" data.

Let's take an example. Suppose we use XML Schema to model the countries of the world:

<xs:element name="Country">
            <xs:element name="Afghanistan" type="countryType" />
            <xs:element name="Albania" type="countryType" />
            <xs:element name="Zimbabwe" type="countryType" />
            <xs:element name="Other" type="countryType" />

Since the countries of the world are ever-changing, we include an "Other" element in anticipation of some future, unforeseen country.

It is easy to imagine assigning a program component to Iceland:


But what is a program component to do when it encounters the "Other" country:


There is no "Other" country and so any operation that we might assign to the data would be nonsensical.

Stated another way: 

	"Other" data is not machine-processable. The reason
	for using XML is that to enable machine-processing. 
	But by incorporating non-machine-processable 
	"other" data one's own objectives are defeated.

"Okay, suppose that I avoid using an <Other> element and, say, a new country emerges; what should I do?"

Answer: the real world has changed (there is a new country). Your data model must be updated to reflect the real world. So update your XML Schema and in your program add a component for the new country.

Comments welcome.


[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