I agree with Bruce that "other" sometimes indicates a failure or limitation of analysis.
But some lists cannot be enumerated; sometimes the world changes; sometimes categories change; some things are one way in one part of the world but a different way elsewhere; some things requested should not be disclosed.
Gender and post addresses are two things that people expect are quite fixed, but turn out not to be.
And then some "other" facilities in xml are dictated by the unlayered nature of xsd and dtds: conservative and slow development and distribution practises that are appropriate for base vocabulary elements may not be appropriate for code lists maintained on other timelines. If your schema cannot track the codelists used, it needs a temporary other for interim parking.
Rick
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
571-272-9004
-----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:complexType>
<xs:choice>
<xs:element name="Afghanistan" type="countryType" />
<xs:element name="Albania" type="countryType" />
...
<xs:element name="Zimbabwe" type="countryType" />
<xs:element name="Other" type="countryType" />
</xs:choice>
</xs:complexType>
</xs:element>
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:
<Country>
<Iceland>...</Iceland>
</Document>
But what is a program component to do when it encounters the "Other" country:
<Country>
<Other>...</Other>
</Document>
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.
/Roger