Generating xsd:import statements in XSD Schema

[Rick Sjogren]

Hi all,

I would like to know how to get the XSD Schema generation to generate the <xsd:import/> command for a namespace.

What I have modelled is a class structure for a Common Messaging Model that is structured similarly to the UN/CEFACT CCTS. With this structure, Core Data Types (cdt), Qualified Data Types (qdt), and Unqualified Data Types (udt) are separate packages with separate namespaces that I really want generated into separate files.

The thing is that I can generate the separate files but that I have to then manually add the <xsd:import/> statements, which sort of invalidates the whole XSD generation thing as I have to remember to add them after regenerating the XSDs.

Can anyone please give me some guidance?

Regards,
Rick

[thomas.kilian]

As nobody has answered I know at least that here's another hole. XSD modelling does not seem to be used very widely.  

[Rick Sjogren]

Hi abcde,

Your response has prompted me to respond and wind up this thread.

I found out from Sparx that the way to get the schema import lines to work properly consists of two steps:

1. For each package with a namespace, add a Tagged Value called "schemaLocation" and put in the URI of the xsd to find.

2. Build up your XSD structure in EA from the ground up. Start with the lowest level of datatype or element , first, and progressively set up the higher levels by adding references to the lower level elements/types. Use the ellipses (...) to the right of the Type drop-down list and select your element/type form there. This will set up the link which will cause EA to automatically add the xsd:import statement for the xsd that the selected element/type resides in. Note that it uses the schemaLocation tagged value that you created in Step 1.

As for building up the XSD element/type hierarchy, I mimicked the OASIS ebXML standard of having (from lowest level to highest):
* XML Datatypes (eg. int, string)
* Unqualified Datatypes (eg. IdentifierType, NameType)
* Qualified Datatypes (eg. CustomerIdentifierType, ProductNameType)
* Core Components (eg. CustomerIdentifier, ProductName)
* Aggregate Components (eg. Customer, Product)
* Message Payloads (eg. CustomerStatements, ProductCatalog)

To make it easier, it is best to create separate models for each level. That way, you can ensure that you are getting the element/type from the correct place.

As for Step 2, it would be nice to add a schemaLocation to each namespace in the namespace list for a schema. Thus, if it is left empty, no xsd:import is created, and if it is specified, an xsd:import is created. I forgot to ask for this for 7.1 and I figure that it is a bit late now.

HTH,
Rick

[«Midnight»]

It is not too late Rick,

That does not mean it won't get into the mix, but it is definitely worth making the point.

Depending on how you view this, make a feature request or a bug report. They cannot fix what they don't know about. And for the requests they are aware of it helps Sparx to know what is actually needed by the community.

David

[Rick Sjogren]

Done.  

Rick

[thomas.kilian]

Hello Rick,
thank you very much for the feedback. It really gave me some inspiration and I'm sure others will profit from your answer too.

Can you tell me to which extend you are using XSD schema generation with EA. Do you also use reverse engineering?

[Rick Sjogren]

Hi abcde,

Yes. We do a little bit of reverse engineering. We use the V7.1 beta and it does a much better job of reverse engineering and round-tripping than V7.0. I still dislike EA's making decisions on my behalf but they've reduced it to a level where I can live with it.

Where I'm currently working, I'm using EA to create a logical common messaging model for the organisation. As they've never done this before, I'm also setting up the principles, guidelines, framework, and standards for the organisation, too.

I also have to show the way with Architectural Frameworks where I've chosen Zachmann for the rows (ie. contextual, conceptual, etc) and US OMB Federal Eneterprise Architecture (FEA) for the columns (performance, business, service component, data, and technology reference models). The organisation has an Enterprise Data Model (EDM) and we've committed to showing full traceability from the EDM to the physical XSDs. Of course, this traceability is mostly at the attribute level as an EDM (relational) is very different to a XSD (hierarchical).

EA's ability to link things together within an architectural framework is very useful. And it's the linking that gives you the power. EA's not ideal for this (OWL is better) but it gives us a terrific start. And we can export it in XMI to import into a fully-featured metadata repository when we do finally get one.

My principle inspiration for the XSD modelling is OASIS UBL and UN/CEFACT Modelling Methodology (UMM). The other inspiration is the Australian Government GovDex website. I would have liked to use the UMM addin but I'm not sufficiently comfortable to be able to use it productively in the timeframe we had.

We have used EA exclusively for modelling common messages and for generating the XSDs from them. We've modelled our XSDs as UML diagrams and we've stereotyped our classes and attributes using the standard off-the-shelf XSD stereotypes that EA provides (and, yes, I've read the book that they used but it doesn't really add much to what EA already has. FYI, the author runs the xmlmodelling.com website.).

My only concern with XSD stereotyping of the logical class model is that it blurs the line between a logical model (the class diagrams) and the physical model (the XSDs). We use the logical model to map flat files (csv) as well but it isn't obvious to others because of the stereotyping. This is where a clear division between logical and physical becomes important in ensuring that staff understand the difference and work appropriately.

HTH.
Rick

[thomas.kilian]

Hi Rick,
unlike you I'm not that happy with the XSD import (but for the same reason as you are unhappy with it). Especially the merging of element with complexType is awkward and leads to quite some manual afterwork. It was quite (no, not really, but okay) easy to produce a XSD export which now does a pretty good job. I refrain from writing an import as well as the pressure for import is not that high and the manual work is acceptable for the time being. We'll se what the future will bring.

It would be a big relief if Sparx would use scripts for these im-/export tasks (and other things). I abandoned hope to receive such a thing in my life.

Currently I'm working as a consultant for a large car manufacturer in Germany. But I'm afraid they are quite some way off to make use of Zachmann. At least they start using UML along with a tool like EA which is promising though.

Regarding the XSD mapping: all that stuff is relatively new to me. So I'm struggling on may way and try to grip each straw I find. So your feedback was really helpful to me.

Thanks  

[salayande]

Hi Rick,

I am pleased to know that other people have arrived at similar conclusions as I have.

I joined an airport operator about a year ago and I was tasked with the development of a shared business vocabulary represented as a UML model from which I was created XSD components for implementation in an Enterprise Service Bus.

Re-use was central to my strategy. Re-use had to be at the conceptual and logical levels because it was easier to identify design patterns at those abstraction levels.

Fortunately for me the OASIS UBL TC had also used Sparxsystems EA to model UBL. I obtained the model and imported it into my development environment.

I also adopted the UMM Add-In because it creates a useful model structure aligned to the Zachman framework and it also focuses on collaborative process models. Using the tool was not intuitive because of the complexity of the UMM specification (has been made simpler in the new version 2.0). The Add-In as exists is also a prototype and is being developed.

I chose to use the standard features in EA for now. I have also acquired a tool known as GEFEG.FX which I am learning to use because of EA's inability to generate XSDs based on either the UNCEFACT or UBL's Naming and Design Rules (NDR). My team has been evaluating other tools including Contivo and Semantic Integrator.
The evolution of Hypermodel developed by Dave Carlson is also of interest to us.

I made several suggestions to Sparxsystems on the XSD Round-trip engineering and also on the NDRs but I am afraid that this distracts from actually getting my work done. I believe that the product will improve in time.

Sparxsystems are working hard to improve on a great tool, may I suggest that you continue to make suggestions to them. They will also appreciate specific use cases that improves the tool.

kind regards

Segun