If anyone ever encounters a similar constraint, I resolved the problem I had with maintaining two separate versions of a schema (one with constraints and non-string data types, one without) by writing a stylesheet that removes the restrictions in my schema before the source generation is called. I made this part of my ant build with a style task.
The stylesheet follows (note that the stylesheet only handles the data types and restrictions used in my schema -- also, there are some schema-specific portions at the bottom e.g. changing minOccurs only for those elements that are children of other specific elements). <?xml version = "1.0" encoding = "UTF-8"?> <xsl:stylesheet xmlns:xsl = "http://www.w3.org/1999/XSL/Transform"; version = "1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:rfh="http://www.citibank.com/latam/regionalfilehandler";> <xsl:output method = "xml" indent = "yes"/> <!-- Identity transform for most nodes --> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> <!-- Change restrictions with various bases to xsd:string --> <xsl:template match="@base[. = 'xsd:date'] | @base[. = 'xsd:long'] | @base[. = 'xsd:nonNegativeInteger']"> <xsl:attribute name="base">xsd:string</xsl:attribute> <xsl:apply-templates/> </xsl:template> <!-- Change elements with various types to xsd:string --> <xsl:template match="@type[. = 'xsd:date'] | @type[. = 'xsd:long'] | @type[. = 'xsd:nonNegativeInteger']"> <xsl:attribute name="type">xsd:string</xsl:attribute> <xsl:apply-templates/> </xsl:template> <!-- Remove enumerations --> <xsl:template match="xsd:enumeration"/> <!-- Remove string facets --> <xsl:template match="xsd:length"/> <xsl:template match="xsd:minLength"/> <xsl:template match="xsd:maxLength"/> <!-- Remove integer facets --> <xsl:template match="xsd:totalDigits"/> <xsl:template match="xsd:fracDigits"/> <!-- Make all elements under the data elements optional --> <xsl:template match="@minOccurs[ancestor::xsd:element[@name='payment-information'] | ancestor::xsd:element[@name='legal-document'] | ancestor::xsd:element[@name='invoice']]"> <xsl:attribute name="minOccurs">0</xsl:attribute> </xsl:template> <!-- Add a minOccurs attribute to those that don't have one, under the data elements --> <xsl:template match="xsd:element[not(@minOccurs) and (ancestor::xsd:element[@name='payment-information'] | ancestor::xsd:element[@name='legal-document'] | ancestor::xsd:element[@name='invoice'])]"> <xsl:copy> <xsl:attribute name="minOccurs">0</xsl:attribute> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet> Cheers, Raman > Raman, > > Make a copy of your schema. Change the type of the field to a string. > Regenerate the classes using the modified schema. > > Now any simple value can be contained in the field. > > --Keith > > > Raman Gupta wrote: > > > > I am involved in a project where I need to support XML that contains > > data that does not match the defined schema. For example, my schema > > specifies that a field is numeric, but the XML may arrive with > > non-numeric values. > > > > What I would *like* to do is to keep the data type information in my > > schema (because this is extremely useful during development and > > testing and other times that data type validation is required), but at > > the same time I need to be able to turn schema validation off so that > > I can unmarshal the XML as-is. > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
