Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Conditional Levels of a Schema

From: "Michael Kay" <mike@--------.--->
To: "'XML4Pharma'" <info@----------.--->, "'Dieter Menne'" <dieter.menne@------------.-->, <xmlschema-dev@--.--->
Date: 4/7/2009 5:09:00 PM
> 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/


From info@X... Tue Apr 07 15:55:33 2009
Received: from maggie.w3.org ([193.51


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent