Sara Yeager sent me a question about how to generate an XSD from her data model for developers on her team:
I used the ARTS model as a template for the definition of a Retail Transaction and Retail Transaction Line Item. I know you’ve worked with ARTS and are familiar with this super/sub type structure.
In working with our solutions architects, they asked if I could produce XSD for them from the data model from which they could create the Retail Transaction business object. So, what I did was exported the model using MIMB into XSD format and provided it to them. What they said was that the XML created wasn’t what they had expected. It evidently wasn’t formatted in the manner they expected, with relationships and “choices” not included.
I am absolutely not an XML/XSD expert, but what it appears to me is that the XSD created from ERwin defines the data model structure and what they are looking for is more functional XML to use in the creation of their classes etc. So, perhaps there’s an additional conversion or something which must be done in order for the XML to be usable, according to them.
What I’ve learned about these sort of generation requests is to enter …
Sara Yeager sent me a question about how to generate an XSD from her data model for developers on her team:
I used the ARTS model as a template for the definition of a Retail Transaction and Retail Transaction Line Item. I know you’ve worked with ARTS and are familiar with this super/sub type structure.
In working with our solutions architects, they asked if I could produce XSD for them from the data model from which they could create the Retail Transaction business object. So, what I did was exported the model using MIMB into XSD format and provided it to them. What they said was that the XML created wasn’t what they had expected. It evidently wasn’t formatted in the manner they expected, with relationships and “choices” not included.
I am absolutely not an XML/XSD expert, but what it appears to me is that the XSD created from ERwin defines the data model structure and what they are looking for is more functional XML to use in the creation of their classes etc. So, perhaps there’s an additional conversion or something which must be done in order for the XML to be usable, according to them.
What I’ve learned about these sort of generation requests is to enter into a more detailed dialog with the developers to find out what they really want. XSD is just the name of a very vague file format. Calling it a format is even a stretch. It’s sort of like someone asking you to provide the data model “in a spreadsheet”. You can generate a million spreadsheets from a data model without providing any value, depending on what the consumer is really looking for. In addition, the tips below also apply to requests for “some DDL” from the data models, too.
I have used the following questions to help derive what they need:
- What, exactly, will you be using the XSD for? This is not a query asking the developer to justify their request, but to be much more specific in what type of XSD they need. It may also lead to a response where the best type of file to provide them is not an XSD.
- Are you using this as a one-time method to get the data model information into a tool? Which tool? What formats will it import? Does it have any special requirements for the format or standards for the file?
- Are you expecting this provision of the data model to be repeated over the course of the project? When something changes in the model? On a fixed schedule? Only when the model is officially released?
- How will you incorporate changes to the model into your tool? If you are annotating or modifying the model objects, how will you reconcile those changes with changes in the data model?
- Do you need the entire data model or just parts of it?
- Do you want the physical (database) names, the logical, or both?
- What properties (datatypes, domains, definitions, notes, UDPs/Attachments) do you want with the file?
There is often a lot of resistance to answer the questions because many times they just want to be able to browse the model in a tool that they are comfortable working with, which is fine if they understand that data models include all kinds of information that their tool may not support. Their tools may also require modifications to the model such as truncation of names or definitions. I can guarantee that every time to move data from one system to another, it gets changed.
Other times, they want to do things that are less benign, such as modify the model to generate development databases. Depending on your project methods, that may or may not be a good thing.
The reason you want to know what tool is that the Meta Integration Bridge (MIMB) may offer a more targeted, direct format than just an XSD. For instance, I get requests to generate XSDs for common development tools, but I can produce a much more meaningful and valuable file by generating a file that all the objects in the right places for the exact version of the tool they are using. For instance, the XMI possibilities often lead to better integration with other tools.
Also, if they are reporting something is “missing”, then it means that either you didn’t choose to include it in the Destination tab of the MIMB or that the external format (or MIMB) does not support it. For instance, some tools don’t include relationships in the data model when choosing XSD as the target format.
The best way to figure out what the requester is looking for is to ask for a good example of what they expected the file to look like. You could ask them to prepare an XSD that has 3-4 entities and a handful of attributes. In reviewing this, you can best determine which export format to use.
If there are still issues with the format or content of what you are providing, you may have to negotiate with them to provide enough content that they can develop what they need from what you deliver.
You can provide them a file that has all the specifications about a data element so that they can derive a process or object-focused structure for their needs, but they will need to design a new file by bringing together all these data elements. You can work collaboratively with them on this, but that the model you are providing won’t instantly do design for them.
You must be able to review their designs for compliance with the underlying business rules inherent in the data model. For instance, it is typical for a message or object to leave out certain elements that are more appropriate for persistence and historical/traceability needs. So they can leave this stuff out and still be compliant. But they can’t re-design business rules by ignoring the fact, for instance, that ITEMS often have multiple SKUs or GTINs. Or that RETAIL TRANSACTIONs sometimes result in no tendering being made (exchanges, credits, etc.).
The key, as in all deliverables of the data model, is to not be tempted to just produce a file based on tool defaults, throw it over the wall and tell others to deal with it. I see these request for derivations of the data models be great indicators of the value of your hard work. There are those who would not come to you to request these files, but just try to key it in by reading a print out. That’s labor intensive and mistake prone. So treat all these requests for better exports from the model as compliments. They are.