[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [xml-dev] Schema design pattern question]
Forwarding from XML-DEV to CAM TC, as this looks like a good job for CAM. I would be happy to forward back to the XML-DEV listserv any comments, even though the poster is looking for an immediate solution. Kind Regards, Joe Chiusano Booz | Allen | Hamilton
--- Begin Message ---
- From: Arno Hollosi <arno.hollosi@cio.gv.at>
- To: xml-dev@lists.xml.org
- Date: Mon, 17 Nov 2003 17:39:07 +0100
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 ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>--- End Message ---
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]