Namespaces and Includes

When working with XML and XML Schemas, Namespaces makes it a bit difficult. The main issue with Namespaces in my opinion is the difficulty in dealing with the prefix to the namespace uri mapping. The software used to generate Visual Schemas has been tested with several different standards (as can be seen from this blog history), yet, very rarely some issues are identified in the software. As part of generating the Visual Schemas for Election Markup Language (EML), two additional issues were uncovered. One was an issue where the name of the element instead of the qname was used and it’s a outright implementation bug. However, the other one was more interesting.

EML schemas include additional schemas (core and external) and these included schemas include a few more schemas that have their own namespaces. The current Visual Schema software implementation computed the namespace prefix to uri mapping based only on the outer most schema. So far, all the other standards worked with this approach (either because they didn’t have multiple namespaces or they included all their namespaces in the outer schema). However, this didn’t work with EML since additional namespaces were defined in the included files. This makes it a bit complicated to deal with because usually developers doesn’t care about explicitly loading the included documents and just rely on the XML Schema parsing API to do it for them. So, there are two approaches to deal this issue

1) Recursively navigate through the XML Schema DOM and get all the included schemas and gather the namespaces defined in them. Ofcourse, this has the issue of making sure that the relative paths are properly converted to absolute paths.
2) Implement a custom Input Resolver and on the fly as the XML Schema parser is fetching the included schemas, gather the namespaces.

I am yet to decide on the approach I want to take, mostly will go with the approach 2. However, to deal with EML, the included namespaces are hard-coded for EML schemas.

My recommendation for anyone creating XML Schemas is perhaps to redefine all the namespaces from the included schemas (recursively) in the outer schema. Otherwise, developers working with the schemas might face challenges depending on the sophistication of the tools they are using.

Call For XML Message Complexity Score Calculation Ideas

The open standards are usually quite complex as they tend to be generic. Some messages may be more complex within the standards than the other. Some messages may be more important for a specific company than the other. However, in most cases, it is possible to implement the standards in multiple phases. To be able to plan better and come up with good estimates on the work needed, understanding the relative complexity of the messages is important. Some messages may be just 2/3 level deep with just a handful of attributes and elements while the others may be much more elaborate with a depth of 10 or more and thousands of elements.

VisualSchema is looking for input on how to compute the complexity score of the various messages within a standard.