Oh the irony of this question appearing on XML-Dev ! Isn't the provision of 'Other' the whole point of *Extensible* markup language? Ironic too that without that hack-ish xsd:any (or xsd:anyAttribute) in a schema, XML constrained by an XSD schema is not particularly extensible. So what does XML mean by 'extensible'? I guess what people usually want is semi-constrained markup, codelists, etc. Fully-constrained is what the coder wants but the business rarely copes with fully controlled vocabularies. And yet what real value is there actually in a partially-controlled vocabulary? Less value perhaps than either fully controlled or uncontrolled. Yet so often it is the preferred choice of the analyst. ---- Stephen D Green On 9 February 2014 14:27, Costello, Roger L. <costello@mitre.org> wrote: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 _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php_______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php