Re: [xml-dev] The real world doesn't have an "other xyz", neither should

["Bill Kearney" <wkearney@gmail.com>]

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.