Lists Home |
Date Index |
- To: email@example.com
- Subject: Schema design pattern question
- From: Arno Hollosi <firstname.lastname@example.org>
- Date: Mon, 17 Nov 2003 17:39:07 +0100
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
I have a problem which I hope you can help me to solve:
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.?
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
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 ...
Leiter Technik und Standards
Stabsstelle IKT-Strategie des Bundes / BKA
Wagramerstraße 4, 1220 Wien
Tel: +43 1 53115 6141 Fax: +43 1 2697861