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] Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community

> 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

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

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

[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