A1. hmmm, how much of that is double-speak for "people that are either too
stupid or too cheap to understand what an actual 'investigation' would
resemble"... Clearly it would benefit everyone involved to either raise the
level of understanding or at least grasp what such an endeavor should
actually entail. THAT would be an article worth reading.
A3. "lies" is needlessly polarizing language. Yes, it's data that doesn't
fit, but it's hardly the equivalent of lying. You're asking/allowing them
to 'make something up'. If you don't define how this is handled then you're
asking for trouble. But using the term 'lies' is ridiculous.
A4. Agreed, and this is where I've noticed a fair bit of cleverness emerging
in various systems. Just enough 'hinting' to help without calling a halt to
the process and thus encouraging unproductive interaction (false or missing
data, etc). Revenge of Clippy, without the annoying icons.
-----Original Message-----
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).
