The in-between for everyone is at least having a definition of what's a
legitimate way to express data that can be collected but the model does not
accommodate effectively at that point in time. As in, where do I put it
when there's not a correct bucket for it?
This is, perhaps, as much a UI argument than anything else. It's all about
how you keep the system usable to the various parties involved. Without at
least "some way"; some sort of defined understanding, you end up with chaos.
Now, you're going to get chaos anyway (such is the nature of users) but
there's no reason to be stupid about it. Don't be ignorant of the
possibilities, nor pedantic on insisting upon some unattainable level of
'perfection'.
Analogies like emerging or changing countries are useful and not something
trivial, but considering them (and other values) does benefit from being
realistic about WHY you're managing that information. Who gives a flying
fuck if the database won't let you enter a value for country X if that
country's not in your mission's target market? Oh wait, you've merged
organizations with one that DOES serve that market... ooops.
But at the same time if you're got operators dumb enough not to realize the
abbreviation for one country being the same as a particular locality
(states, provinces, etc) then that's probably a good place for the UI to be
more sensible about working around their fallibility. But only as sensible
as necessary, and not more. Using rigid analysis on inputs can bite you.
As in, using a database to "prove" the address info as valid, requires that
validation source is likewise accurate and up to date. But data on which
mechanisms like that might depend changes all the time, if you're too rigid
about it you then open up the door for operators being 'clever' about it...
But then this really doesn't have anything specific to limit it just to XML,
it's true of any system for managing data.
-----Original Message-----
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.
