4 Replies Latest reply: Jun 14, 2011 10:58 AM by user8781044 RSS

    Complex xsd with many nested types

    user8781044
      Anyone got a good idea about how to flatten large complex nested xsd files with many nested types to use quickly to generate an fml field tables? I have a very generic old tuxedo process which takes xml but whose xsd definition is 128k, is there a utility or snaything somone can think of which would build and fml field table from a large xsd like this.

      Jim Urban
        • 1. Re: Complex xsd with many nested types
          Maurice G
          Hello Jim,

          SALT 11gR1 and above come with the mkfld32fromschema (for FML32) and mkfldfromschema (FML) to produce field tables from .xsd files.

          Note that you may still have to deal with name conflicts if nested elements have identical names.

          Cheers,

          Maurice Gamanho
          • 2. Re: Complex xsd with many nested types
            user8781044
            Maurice,

            Thanks that is great but when I try this i get nothing maybe something I am missing?

            mkfld32fromschema -b 200 -i template.xsd -o jimbo

            jimbo contains nothing.

            template.xsd contains:

            *<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' elementFormDefault="unqualified" >*

            *<xs:element name="template" type="rootType" />*

            *<xs:complexType name="rootType" >*
            *<xs:sequence >*
            *<xs:element name="templateId" type="templateIdType" />*
            *<xs:element name="datelastused" type="datelastused" />*
            *<xs:element name="numberuses" type="numberuses" />*
            *<xs:element name="lastuserncid" type="lastuserncid" />*
            *</xs:sequence>*
            *</xs:complexType>*
            *<xs:simpleType name="templateIdType" >*
            *<xs:restriction base="xs:string" >*
            *</xs:restriction>*
            *</xs:simpleType>*
            *<xs:simpleType name="datelastused" >*
            *<xs:restriction base="xs:string" >*
            *</xs:restriction>*
            *</xs:simpleType>*
            *<xs:simpleType name="numberuses" >*
            *<xs:restriction base="xs:string" >*
            *</xs:restriction>*
            *</xs:simpleType>*
            *<xs:simpleType name="lastuserncid" >*
            *<xs:restriction base="xs:string" >*
            *</xs:restriction>*
            *</xs:simpleType>*
            *</xs:schema>*

            What am I missing?

            Jim
            • 3. Re: Complex xsd with many nested types
              Ed Heeren-Oracle
              Jim,

              mkfld32fromschema is designed to look for <xsd:element name="+name+" type="+type+"> elements within schema files. If you installed the SALT samples, you can look at the $TUXDIR/samples/salt/sca/uBikeSCA/uBike.xsd file, which contains

              <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="tuxedo" targetNamespace="tuxedo">

              <xsd:complexType name="BikeInventory">
              <xsd:sequence>
              <xsd:element name="BIKES" type="Bike" minOccurs="0" maxOccurs="unbounded"/>
              <xsd:element name="STATUS" type="xsd:string" maxOccurs="1"/>
              </xsd:sequence>
              </xsd:complexType>

              <xsd:complexType name="Bike">
              <xsd:sequence>
              <xsd:element name="SERIALNO" type="xsd:string"/>
              <xsd:element name="SKU" type="xsd:string"/>
              <xsd:element name="NAME" type="xsd:string"/>
              <xsd:element name="TYPE" type="xsd:string"/>
              <xsd:element name="PRICE" type="xsd:float"/>
              <xsd:element name="SIZE" type="xsd:int"/>
              <xsd:element name="INSTOCK" type="xsd:string"/>
              <xsd:element name="ORDERDATE" type="xsd:string"/>
              <xsd:element name="COLOR" type="xsd:string"/>
              <xsd:element name="CURSERIALNO" type="xsd:string"/>
              </xsd:sequence>
              </xsd:complexType>

              </xsd:schema>

              The command mkfld32fromschema -b 200 -i $TUXDIR/samples/salt/sca/uBikeSCA/uBike.xsd produces the following output:
              #NAME ID TYPE FLAG COMMENT
              #---- -- ---- ---- -------
              *base 200
              BIKES 1 fml32
              STATUS 2 string
              SERIALNO 3 string
              SKU 4 string
              NAME 5 string
              TYPE 6 string
              PRICE 7 float
              SIZE 8 long
              INSTOCK 9 string
              ORDERDATE 10 string
              COLOR 11 string
              CURSERIALNO 12 string

              Note that since the type="Bike" associated with name="BIKES" does not start with xsd: , this is assumed to be a nested fml32 type.

              In your case, you can get some output from mkfld32from schema by changing xs: to xsd: in the schema file. The command sed 's!xs:!xsd:!g' <template.xsd | mkfld32fromschema -b 200 -o jimbo will write the following to jimbo:
              #NAME          ID     TYPE     FLAG     COMMENT
              #----          --     ----     ----     -------
              *base 200
              template 1     fml32
              templateId 2     fml32
              datelastused 3     fml32
              numberuses 4     fml32
              lastuserncid 5     fml32

              Note that the output is being produced from the date at the top of the file, such as
              *<xs:element name="datelastused" type="datelastused" />*
              Since these types do not start with xsd: the output type is fml32.
              In order to parse the data in the lower part of the file such as
              *<xs:simpleType name="datelastused" >
              <xs:restriction base="xs:string" >
              </xs:restriction>
              </xs:simpleType>*
              it would be necessary to do more extensive editing on the file contents before passing it to mkfld32fromschema.

              Regards,

              Ed
              • 4. Re: Complex xsd with many nested types
                user8781044
                Ed,

                Thanks alot that is really helpful.

                Jim