[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [cam] [Fwd: [xml-dev] Schema design pattern question]
Joe, Thanks for catching this for us. First of all Arno needs to urgently look at the OASIS CIQ standard, that is widely adopted for doing exactly what he wants. Second - the use of CAM templates does indeed allow him the flexiblity and functionality he is seeking. We are also working with the CIQ team on combining CAM and CIQ together. No need to re-invent the wheel here. Thanks, DW. Message text written by "XML: Dev" > 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 <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]