W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2009

RE: Conditional Levels of a Schema

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>
Message-ID: <6A5E3745B8C144A8BD087450224A30CC@Sealion>
> 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
Received on Tuesday, 7 April 2009 15:09:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:16 UTC