Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community

From: "Michael Kay" <mike@--------.--->
To: "'Andrew Welch'" <andrew.j.welch@-----.--->,"'Costello, Roger L.'" <costello@-----.--->
Date: 7/9/2008 3:27:00 PM
> How do you create a single XML vocabulary, and validate that XML 
> vocabulary, for a community that has sub-groups that have overlapping 
> but different data needs?

With difficulty. I've seen the problem more often in a different guise: how
do you design a set of 400 messages for application data interchange that
reflect different information about different events affecting the same
objects?

One approach is to rediscover the concept of subschemas, as used in the
Codasyl database model. (In the relational model, these became views, but
that's a less useful concept in this context.)

You can start with a schema that makes everything mandatory, and construct
from it a subschema in which parts are optional and/or prohibited. Or you
can start with a schema in which everything is optional, and your subschema
can make some parts mandatory. Either way, I think you are using some kind
of process that modifies a schema to create a different schema. Plenty of
users are doing such things by applying XSLT transformations to XSD
documents, but it's not easy. Others are doing it using xs:redefines, which
is not much better. Others are simply giving up: I've seen users stuff
unwanted data into a message because it's too hard to change the schema to
make it optional, and I've seen users relax the schema to make an element
optional for everybody even though there are some contexts where it's
required.

Assertions in XSD 1.1 could be used to make the process much easier. If your
schema is permissive (everything optional), you can add assertions to make
it more constrained.

Michael Kay
http://www.saxonica.com/


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