OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The real world doesn't have an "other xyz", neither should your XML

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS