Hello all,I'd like to first preface this e-mail with an explanation of what I'm using the generateDS code for as it is, as far as I can tell, a little out of touch with what most people are. Through our work on the open source Open Microscopy Environment project (http:// www.openmicroscopy.org) and OME XML (http://www.ome-xml.org) we have come across various code generation challenges with our data model, which is described using XML Schema:
http://www.openmicroscopy.org/Schemas/OME/2007-06/The most recent is in providing an object-oriented API atop our main data model in Java. Essentially, we want to generate Java data structures from an XSD document. As we have a relatively significant amount of meta-modeling going on in our data model, many of the Java tools were either too simplistic or too rigid to use for our purposes. Having used generateDS in the past for simpler data models that we wanted to access in Python it seemed like a logical place to start.
In terms of usage, my focus has been on getting generateDS to parse our XSD document(s) and preserve enough of the XML Schema definition to be used with our Python based templating tools. From a programming perspective this has entailed the tweaking of what I call the generateDS XSD meta-model, which is basically the following classes:
* XschemaHandler * XschemaAttribute * XschemaAttributeGroup * XschemaElement * SimpleTypeElementSo with the background out of the way, I'll start off with a rather nasty problem I have been having with the 1.10a release from August 21st and that is that a lot of the additions in the 1.10a-August release have been made with differing whitespace. These are fixed in the attached patch, though because of its integrated nature may be a bit hard to follow, let me know if a patch just fixing these errors would be helpful.
Because our schema has element complexity that was previously unsupported by the generateDS XSD meta-model, I have added several things to the core generateDS logic which are included in the attached patch:
-- xsd:list element supportxsd:list elements can be used with a child xsd:simpleType which confuses the XschemaHandler stack unrolling. xsd:list element support should allow the following XML Schema definition to be supported in generateDS:
<xsd:attribute name="Foo">
<xsd:simpleType>
<xsd:list>
<xsd:simpleType>
...
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
</xsd:attribute>
-- xsd:enumeration support
The enumerated values for the parent element are resolved and made
available through the instance attribute "values".
-- xsd:union supportIn order to properly resolve and query types which are unions in an XML Schema, an element's membership in an xsd:union is available through the instance attribute "unionOf".
-- extended xsd:choice supportWhen a parent xsd:choice is exists, an element's "maxOccurs" and "minOccurs" values can be inherited from the xsd:choice rather than the element itself. xsd:choice elements have been added to the child element via the "choice" instance attribute and are now used in the "maxOccurs" and "minOccurs" attribute resolution. This should allow the following XML Schema definition to be supported in generateDS:
<xsd:element name="Foo">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Bar"/>
<xsd:element ref="Baz"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
-- minOccurs attribute support
Our templating tools required the availability of the attribute in
addition to the 1.10a-August addition of "optionality". Similar to
the existing API, this is available through the "getMinOccurs" method.
-- More thorough content type and base type resolutionThe existing content type and base type resolution was insufficient for our needs (basically it was unable to handle our more complex and shared element and simpleType definitions) and has been extended to more correctly (I hope :)) resolve the base type and properly indicate the content type of the element. This should provide support for more complex XML Schema definitions in generateDS as a whole. Documentation on the algorithm for how this is achieved is available as comments inside the attached patch.
-- Making top level simpleTypes available from XschemaHandlerAs my code starts after all types have been resolved and I need all the top level simpleTypes to be available for further queries after the SAX parser has completed its work I've made them available as an instance attribute "topLevelSimpleTypes" inside XschemaHandler. If there's a way to do this that's more in line with the heavy use of globals in generateDS, I'm certainly open to suggestions on how to make this easier to work with.
I'd like to thank Dave and the various others who have already made generateDS such a powerful tool to work with XSD documents and hope that at least some of my additions will be useful to others.
Thanks! Ciao. -Chris
generateDS.patch
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
