- From: Michael Kay <mike@saxonica.com>
- Date: Tue, 7 Apr 2009 16:08:42 +0100
- To: "'XML4Pharma'" <info@XML4Pharma.com>, "'Dieter Menne'" <dieter.menne@menne-biomed.de>, <xmlschema-dev@w3.org>
> but, if I do understand it well, this means that you have two > different (versions of the) schemas, with the same namespace, > and different (although slightly different) content. > > This is something, just from a principal point of view, I do not like. > My principle is "new standard (version) => new schema > (version) => new namespace". This is a very important question. I've come to the conclusion that we do need multiple schemas for the same namespace, for a variety of reasons: (a) an organisation defines 400 message types for exchanging data between different applications. There are many data elements shared between these messages. It would greatly restrict reuse of code to have a different namespace for each message type. Yet the validation rules are different: a field that is optional in one message may well be mandatory in another. (b) Different validation rules apply to the same document at different stages in its life-cycle. You don't want to apply the same level of validation to an internal draft document as you do to a final published document. Yet both have to use the same namespace. (c) The schema evolves. I don't believe it is practical to change the namespace every time the schema changes - again, because that inhibits code reuse. You want to be able to evolve gracefully, which means for example that when you expand the range of values allowed for an attribute, existing code continues to work provided the newly permitted values do not appear in the instance, and might even work in the presence of the new value, if the code was carefully written. Changing the namespace means that everyone has to change their code at once, which simply doesn't work. So the problem is that to identify a schema component, knowing the namespace (and local name) isn't enough. There needs to be some other handle to identify the "version" or "variant" we are after. I would like to see this formalized, so that different versions/variants of the same schema component can co-exist. At the moment the only identifier available is the schema location, which is very weak for two reasons - (1) it's an address rather than a name, and (2) the specs are full of stuff about it only being a hint. Michael Kay http://www.saxonica.com/
Received on Tuesday, 7 April 2009 15:09:39 UTC