Schema design pattern question

[Arno Hollosi <arno.hollosi@cio.gv.at>]

Hi,

I have a problem which I hope you can help me to solve:

Short form:

how to define a generic schema that can easily be restricted (i.e. 
tailored to some application) and still used with todays XML and SOAP 
frameworks which cannot deal with derived types correctly? Is there a 
design pattern for such generic schemas that are used in a plethora of 
other schemas with different restrictions etc.?

Long form:

We are in the process of defining an XML schema for basic person related 
data: name, date of birth, sex, marital status, address, ...
The schema is going to be used as standard schema within Austria's 
e-government projects.

The schema is defined as a series of complexTypes, i.e. "name" is a 
complexType consisting of "givenname","surname", etc. The "person" type 
consists of such complexTypes e.g. "name", "address", etc. Abstract 
types and substition groups are used as well, e.g. AbstractPersonType is 
the base for CorporateBodyType and PhysicalPersonType.

The nature of the schema is that it poses no restrictions to values as 
different applications have different requirements, e.g. string length 
of "givenname" is unlimited . Additionally almost all elements in the 
schema are optional (minOccurs=0), as e.g. marital status may be 
relevant for one application but not for another.

The problem arises when this schema should be used as part of a SOAP 
interface with doc/literal encoding. In that use case you want the 
schema to be as restrictive as possible, so that XML frameworks can 
generate proper classes, and also that a validating parser does most of 
the syntax checking work for you.

The clean way would be to derive new types by restriction and use those 
types for the interface schema. Maybe we would need a series of derives, 
as some of the restrictions cannot be dealt within one derivation (e.g. 
first restrict "address", then restrict "person" to use the restricted 
address type). Maybe derive by extension will be used as well.

The problem: most SOAP frameworks do not deal with derivations 
correctly. I.e. if we specified such a schema, noone could use it within 
SOAP interfaces, as current frameworks cannot deal with it. Not to 
mention that we have to deal with programmers who have problems grasping 
even basic DTD syntax - explaining something as complex as the resulting 
schema could become a support nightmare.

I googled around but found nothing relevant for this issue.

Our last ressort (ugly as it may be) is to write the generic schema and 
tell application developers to copy&paste it into their namespace and 
(while doing so) to make the restrictions by hand directly in the schema 
source (i.e. not by schema mechanisms). This results in many "instances" 
of the generic schema in different namespaces, all based on the same 
element and type structure.

Any other idea how we could solve the issue "clean spec" vs. "real 
world"? Is there a design pattern for such generic schemas that are used 
in a plethora of other schemas with different restrictions etc.?

Any help appricated ...

regards,
/Arno

-- 
Leiter Technik und Standards
Stabsstelle IKT-Strategie des Bundes / BKA
Wagramerstraße 4, 1220 Wien
Tel: +43 1 53115 6141  Fax: +43 1 2697861