Reputation: 41
I am going through a simple XSD and manually grabbing XPaths, elements, attributes and documentation and copying it into Excel.
Doing manually is not efficient for longer/complex XSD, is there any way to automatically extract this information?
XML Spy, Oxygen XML, and Liquid have options to generate schema documentation but not in tabular format. It's easier to apply filters when the data is in tabular format as it helps when reviewing with non-technical folks and coming up with requirements.
Upvotes: 1
Views: 3132
Reputation: 1132
Using the Python library xmlschema one can easily generate a dictionary representing the schema (similar to the Clojure library xelery)
{
"root": {
"multiplicity": [min, max],
"type": "RootType"
"name": "RootElement"
"elements": {
....
}
}
}
From this dictionary one can generate an Excel file using the Python library openpyxl (or docjure in Clojure).
For example, a schema of the form:
Root:
- Customers: List[Customer]
- Orders: List[Order]
Customer:
- CustomerId: str
- Name: str
- Address: Address
Order:
- CustomerId: str
- OrderId: str
- ShippingAddress: Address
Address:
- Street: str
- PostalCode: int
- City: str
can be mapped to an Excel Workbook with the following sheets:
Field Name | Value |
---|---|
Customers | Customers |
Orders | Orders |
Field Name | Value | Value |
---|---|---|
CustomerId | ID1234 | ID6789 |
Name | John Smith | Mary Jones |
Address | Address | Address |
Field Name | Value | Value |
---|---|---|
Street | Sesame Street 12 | Sesame Street 21 |
PostalCode | 12345 | 12345 |
City | Metropolis | Metropolis |
Analog to customers
While for relatively simple schemas this can be useful (I implemented this mapping for a client that wanted to use Excel as a GUI for generating SOAP requests), the previous answers are correct. In general, Excel is not the right GUI for generating XML from a schema. There are ways to generate a GUI from an XML schema:
Upvotes: 0
Reputation: 163262
You're right to observe that almost any attempt to do this is going to hit limits as the schema becomes more complex, and you will be constantly trying to enhance your tool to cope with more XSD complexity, until you realise that your whole approach is flawed.
First: don't try to work off the source XSD documents; work off the compiled form of the schema component model (SCM) produced by a schema processor instead. There are various ways of doing that. Xerces offers a Java API to the SCM. Saxon offers an XML representation of the SCM, and also a set of XPath extension functions to navigate the SCM. The advantage of using the SCM is that you insulate yourself from a lot of the cosmetic differences between different ways of writing the same schema, e.g. attribute groups, model groups, xs:include, named versus anonymous types.
Second: a lot of people like spreadsheets and some people are amazingly creative with them. But at the end of the day, representing a graph of complex information in a two-dimensional grid isn't easy. Are you sure this is the right approach? I've seen people instead generate visualisations using HTML and SVG, with extensive hyperlinking, that seem much more appropriate.
Upvotes: 1
Reputation: 111491
Sometimes the right answer is "don't do that"...
Whenever I've seen clients attempt to create a tabular "data dictionary" of the vocabulary and grammar given by an XSD, it's never very satisfying:
Therefore, my recommendation is to use the XSD itself or the automatically derived textual or graphical representation created by your favorite XML/XSD editor — a spreadsheet isn't the right tool for the job.
Upvotes: 1