I am going to soon write up how exactly the Visual Schema are created in more detail later on. But the thing to note is that the UI is all pre-generated static html files. So, depending on the number of complex nodes and the various navigation paths, the number of these static files could be huge. So far, OAGIS™ used to be the most complex with several complex nodes for a few of the messages. papiNet has now over taken that complexity. The entire pre-generated html size is about 3 GB. Visual Schemas for OAGIS&trade Nouns on the other hand occupy only about 0.4 GB. papiNet would have occupied even more, but a few frequent and simple nodes have been deliberately excluded to reduce the storage requirements). This shouldn’t reduce the usability since the nodes that have been excluded are simple text fields and text fields with UOM.
A few reasons why some of the messages have several nodes is
1) Product definition is quite elaborate and recursive (packaging structure).
2) Paper & Wood, the key products of the papiNet standard have tolerances to their values with min and max values. One thing though, instead of defining a complexType of “value with UOM” and use it to define the value, range min and range max values, an alternate choice is to define a complexType that captures the value, UOM as well as range min and max values. In other words, instead of having to say
<Value UOM=”Inch” min=”18″ max=”21″>20<Value>
would have made the payload smaller.
Anyway, even though papiNet has overtaken OAGIS in terms of storage requirement for VisualSchemas, there is another open standard that has a single message that is probably the largest of all the standards. Because it’s very large, I haven’t published it yet. Need to think a bit more on how to reduce the storage requirement, perhaps changing the current architecture of VisualSchemas to suite a certain type of XML Schema that shares some of the papiNet message characteristics.