xsd element name different to complextype name

[Rick Sjogren]

Hi,

I was wondering whether it was possible to generate an xsd where the complextype name is different to the element that uses it. For example, if I model up "<<XSDcomplexType>> Address", EA will generate an xsd that contains the fragment

...
<xsd:element name="Address" type="Address"/>
<xsd:complexType name="Address">
...

whereas what I want is

...
<xsd:element name="Address" type="AddressType"/>
<xsd:complexType name="AddressType">
...

Can anyone help me with this? I don't want to have to edit the generated xsd as that appears to defeat the whole purpose of generating XSDs from UML.

Regards,
Rick

[Paolo F Cantoni]

Hi Rick,

WE do that all the time...  Admittedly, we reverse engineered from an Altova created XSD.

However, the advice applies - set on up externally using your favourite XSD creator.  (If you don't have one, I recommend Liquid XML from http://www.liquid-technologies.com/ - it's free and pretty good).

Reverse engineer that and then see what EA does with it then emulate it...  I can't provide an example since I'm not at work...

BTW: reverse using both forms of representation - I think, from memory, there are differences...

HTH,
Paolo

[Rick Sjogren]

Hi Paolo,

Could you please post a sample for me to try? I created the following XSD out of XMLSpy 2007:

Code: [Select]


<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="SampleAddress" type="SampleAddressType">
   <xs:annotation>
     <xs:documentation>Comment describing your root element</xs:documentation>
   </xs:annotation>
 </xs:element>
 <xs:complexType name="SampleAddressType">
   <xs:sequence>
     <xs:element name="AddressLine1" type="xs:string"/>
     <xs:element name="AddressLine2" type="xs:string"/>
     <xs:element name="AddressLine3" type="xs:string"/>
     <xs:element name="Country" type="xs:string"/>
   </xs:sequence>
 </xs:complexType>
</xs:schema>


Importing the XSD using either method gave me a complexType of SampleAddress.

Regards,
Rick

[Rick Sjogren]

And exporting the imported XSD gives me:

Code: [Select]


<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
 <xs:element name="SampleAddress" type="SampleAddress"/>
 <xs:complexType name="SampleAddress">
   <xs:sequence>
     <xs:element name="AddressLine1" type="xs:string"/>
     <xs:element name="AddressLine2" type="xs:string"/>
     <xs:element name="AddressLine3" type="xs:string"/>
     <xs:element name="Country" type="xs:string"/>
   </xs:sequence>
 </xs:complexType>
</xs:schema>


And if I manually rename SampleAddress to SampleAddressType and create a toplevelelement of AnAddress, I get the following:

Code: [Select]


<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
 <xs:element name="SampleAddressType" type="SampleAddressType"/>
 <xs:complexType name="SampleAddressType">
   <xs:sequence>
     <xs:element name="AddressLine1" type="xs:string" minOccurs="1" maxOccurs="1"/>
     <xs:element name="AddressLine2" type="xs:string" minOccurs="1" maxOccurs="1"/>
     <xs:element name="AddressLine3" type="xs:string" minOccurs="1" maxOccurs="1"/>
     <xs:element name="Country" type="xs:string" minOccurs="1" maxOccurs="1"/>
   </xs:sequence>
 </xs:complexType>
 <xs:element name="AnAddress" type="SampleAddressType"/>
</xs:schema>


It appears that I can't turn off the automatic creation of elements with the same name as a complexType. And it puts the top-level element at the bottom rather than at the top, where it is supposed to go.

Regards,
Rick

[Paolo F Cantoni]

Hi Rick,

Your usage as shown in the examples you gave isn't quite the same as ours.

The modified example:

Code: [Select]


<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="SampleAddress">
<xs:sequence>
<xs:element name="AddressLine1" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="AddressLine2" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="AddressLine3" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Country" type="xs:string" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Test" type="SampleAddress"/>
<xs:complexType name="GlobalEl1">
<xs:sequence>
<xs:element name="element1" type="SampleAddress" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:schema>


Round-trips (that is export from one package and re-import into another - so it doesn't overwrite the first) OK.

And is closer to our usage.

There are issues with both import and export of stand-alone elements (ie not stereotypes as top-level elements -

Thus your:
<xs:element name="SampleAddress" type="SampleAddress"/>

Does NOT get into the browser NOR appear on the diagram  - but IS imported and re-exported!

There are bugs to report and you should do it since your usage is the one that needs to be fixed.

Does that help?
Paolo

[Rick Sjogren]

Hi Paolo,

Yep, it does.

As per your suggestion, I've raised a bug on this issue. I've also raised an issue on the ref attribute for an element being recorded but not being visible when the xsd is imported.

I'll post the response I get from Sparx when I get it (to help those that come searching after).

Thanks for your help.

Regards,
Rick

[«Midnight»]

Thanks Rick,

Sparx can't fix 'em 'till they see 'em.

The good news is that Sparx is pretty responsive, and XML is one area that they have been improving.

It looks like EA 7.1 should enter beta testing soon, so with luck this is a good time to get your bug report in the queue.

David

[Rick Sjogren]

Hi David,

Thanks, David. That's cool. However, like everyone else, I need it sooner rather than later.  

I'm trying to convince the various powers that be that a UMM-like process for modelling messages is the way to go. Some want me create the XSDs directly from a logical data model against all of the advice from everywhere else. I want to use EA. I don't want this to be one of the points of contention.

Regards,
Rick

[«Midnight»]

I know what you mean Rick.

I've vacillated between using UMM and X12 - not the model but the output - for a few years. Of course I've made no progress. And of course each application (read "client") is unique.

As to the timing, as I've said we're awaiting the EA 7.1 beta. Once this goes through (and perhaps while it is happening) we can expect new EA builds every 2-3 weeks.

In the meantime, you could always write an add-in. Still, I hate to write software only to have it become obsolete - particularly when I am one of the drivers of the obsolescence. But them's the breaks.

Sigh...

David

[bennido]

It appears that I can't turn off the automatic creation of elements with the same name as a complexType. And it puts the top-level element at the bottom rather than at the top, where it is supposed to go.

This is a real pain for me as well. With the XML Schema that EA generates, there's no way of easily telling which element is meant to be the top-level element (as all the elements are top level!).

Is there a way of forcing EA to put a specified element to the top ? Anyone ? Thanks !

[Rick Sjogren]

Hi all,

Sparx responded to my bug reports (as they do) and registered the 'ref' bug as a bug. However, the generation of elements with the same name as a complexType is a design feature and can't be easily changed (as of writing). (And, yes, bennido, it means that you still won't be able to determine which element is the top-level one.)

Apparently, the EA XSD import/export feature makes use of the XSD 'Garden of Eden' design pattern. My request was to make the use of this pattern optional. Thus, when the design pattern is not used, both XSDComplexTypes and XSDElements are generated with the appropriate associations. This would allow me to correctly import UBL XSDs and generate them appropriately, too.

<rant>I hate it when software makes arbitrary decisions about how I should do something. I believe that every developer should read "The Design of Everyday Things" (aka "The Philosophy of Everyday Things" aka "POET") as part of their training so that the "NO SURPRISES!" mantra is drummed into their heads!</rant>

(Takes a few deep breaths...)

Anyway, the solution of arbitrarily combining elements and complextypes into a single complex type on import and naming both complextypes and elements the same on export means that I can't round-trip a XSD. In fact, it reduces EA to the role of passive data dictionary and makes its lauded MDA capability irrelevant at a stroke. And it is all because I am forced to perform post-processing on the generated XSD (to remove the spurious elements and add the suffix "type" to all of the types, etc) - a monumental PITA.

Therefore, if you are reading this, can you please lobby Sparx to get them to change it.

Regards,
Rick

[Paolo F Cantoni]

<rant>I hate it when software makes arbitrary decisions about how I should do something. I believe that every developer should read "The Design of Everyday Things" (aka "The Philosophy of Everyday Things" aka "POET") as part of their training so that the "NO SURPRISES!" mantra is drummed into their heads!</rant>

Say no more!

NO SURPRISES is also known as the "Principle of least astonishment"

The intriguing thing to me is that it actually takes more work to make things inconsistent.

Paolo