[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
- From: "Costello, Roger L." <costello@mitre.org>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Wed, 12 Feb 2014 21:04:26 +0000
Hi Folks,
This has been an outstanding discussion - thank you very much!
Below is a summary of the points that were made. If I missed a key point, please let me know. I plan to formally write up this discussion and post it online; so I want to be sure that I have captured all your points.
***************************************************
Issue: Should XML documents contain an "other" catchall element?
***************************************************
----------------------------------------------------------------
Reasons for using an <Other> element in your XML
----------------------------------------------------------------
A.1 Human limitations: there typically isn't enough time or money to perform an exhaustive investigation to create a list of all possible types of data.
A.2. 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.
A.3 If you don't offer an "other" option, you are asking people to tell lies.
A.4 "Other" can be used as a mechanism to grow your knowledge: every time you receive an XML document containing an <Other> element, add its value to the list of known values.
---------------------------------------------------------------------
Reasons for not using an <Other> element in your XML
---------------------------------------------------------------------
B.1 It represents unexpected, unanticipated data.
B.2 It is an admission that you have failed to identify all the possible types of data.
B.3 It may be an indication that your business process is ill defined or your analysis is incomplete.
B.4 It may be an indication that your level of abstraction is incorrect. Stated another way, you may have picked the wrong level of granularity.
Example: if the XML Schema needs to change
every time a country appears or disappears,
that is going involve a lot of work keeping up
with the real world. Instead of modeling the
real world by actual country name:
<Afghanistan>...</Afghanistan>
<Albania>...</Albania>
...
<Zimbabwe>...</Zimbabwe>
It may be better to have a <Country> element
with a @name attribute:
<Country name="...">
B.5 There is little, if anything, that a machine/program can do with unexpected, unanticipated data (i.e., with "other" data).
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]