Just like well commented code makes it easy to understand, XML Schemas can be augmented with comments as well. This is done using the documentation element within the annotation element. Annotation element can be part of many of the XML Schema constructs.

Visual Schema provided a way to visualize the XML Schema definitions. Now, Visual Schemas can display the annotations as inline tooltips so that the schemas can be studied along with their comments. opentravel visual schemas are the first to get this functionality on our website.

Recently we announced Update to opentravel 2007b. Based on a review of the corresponding visual schemas by the opentravel team, an issue has been identified. This has been fixed and the visual schemas for opentravel schemas has been updated.

The issue identified is an interesting one. At issue is whether using NMTOKENS type as the base type for creating an enumerated restriction simpleType is correct or not. While the XML Schema specification does not explicitly prevent this, it certainly does not seem to be the right thing. Visual Schema code has been fixed to allow this type of schema definition.

A while back Microsoft has released xml schemas for their Office 2003 suite of products. Their download contains xml schemas for Microsoft Word, Spreadsheet, Visio and Project.

VisualSchema is pleased to announce Visual Schemas for Office 2003. Note that the visual schema is created only for Microsoft Project and not the other documents. This is because, while the technology used in Visual Schemas is capable of generating HTML for any arbitrary XML Schema, in the process of converting the dynamically generated forms into static HTML forms for browsing on visualschema.com, the number of HTML pages generated will be huge for certain class of XML schemas. These schemas are mainly document layout centric such as XHTML which are very flexible and allow many loops and nesting that translates to several unique paths. This is understandable because, the definition capturing a document layout has such a characteristic. For example, in case of XHTML, a table cell can contain another table. Because of this, the other XML Schemas in the Office 2003 product suite have not been converted into Visual Schemas.

Amazon SimpleDB is a special storage system optimized for certain class of problems. This service is certainly a welcome addition to the already existing Amazon Simple Storage. While Amazon Simple Storage is, as the name indicates, meant to store small and large files alike and that’s pretty much it and simple, SimpleDB is also simple, but more suited to storage database like data (tables, columns).

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

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.