Visual Schemas For PBCore

The Public Broadcast Metadata Dictionary Project has a schema defined for exchanging the data related to the Public Broadcast industry. VisualSchema.com is pleased to offer Visual Schemas for PBCore.

Visual Schemas For EDGAR (SEC Filings)

EDGAR, which stands for Electronic Data Gathering, Analysis, and Retrieval, is from sec.gov and provides XML standards for the SEC filing documents.

VisualSchema is pleased to announce the availability of Visual Schemas for EDGAR SEC filing XML Schemas.

Unlike most standards published as Visual Schemas so far, each of the EDGAR schemas have a separate version. In addition, the same top-level element edgarSubmission and ownerDocument are used in different messages. Instead, the top level element names should have been the name of the Form such as FormTA-1.

Visual Schemas For HR-XML

HR-XML is creating open standards in the area of HCM (Human Capital Management) similar to what OAGIS did for SCM (Supply Chain Management), creating XML Schema based open standards for BODs (Business Object Documents). What’s more, in their 3.0 draft version, they have started to structure their schemas inline with OAGIS, by arranging them as Nouns and Verbs.

VisualSchema.com is pleased to announce the availability of Visual Schemas For HR-XML XML Schemas.

When tried this on the 2.5 version, there were a few issues faced, identifying the key business objects and secondly, there were also some schema errors such as the Longitude element having only the name and no type. Finally found the HR-XML 3.0 draft version from Less is More: Flattening, Profiling, Slimming: Part 1 and generated the Visual Schemas.

One interesting thing noted with HR-XML is, unlike a few other standards which don’t have any explicit copyright restrictions, HR-XML, atleast for 2.5 has a requirement to mention “Copyright © The HR-XML Consortium. All Rights Reserved. http://www.hr-xml.org” in any references to it. So, to be safe, the HR-XML 3.0 draft Visual XML Schemas homepage contains this statement. As I have been exploring the very many open standards to provide Visual Schemas for them, I have seen most open standards which have friendly licenses but a few have some “legal stuff” in them.

Visual Schemas For PIDX

Looking at api.org, it made me think it’s a website meant for developers and focused on Application Programming Interfaces (APIs). Then, I came to know it’s actually “American Petroleum Institute”. They have XML Standards called PIDX (Petroleum Industry Data Exchange). VisualSchema.com is pleased to announce the availability of Visual Schemas For PIDX XML Schemas.

The fact that PIDX has an Invoice document and similarly there is a OAGIS Invoice, it makes one wonder, why these open standards organizations themselves do not collaborate among themselves. If the reason for PIDX to have it’s own Invoice document is because the needs of Petroleum Industry are different, then every industry can choose to have it’s own messaging standard for the transactions and that may not be the best thing.

One Specification, Many Standards, Different Designs

A single XML Schema specification is used in many open standards using different design choices. In this VisualSchema.com blog, along with announcing the availability of a specific standard as a Visual Schema, any design choice specific to the particular standard will be briefly discussed. So far two such choices have been discussed, XML Schema: Is Extensible Value List A Right Design? and Visual Schemas For B2MML.

Here is another issue related to GS1 GDSN. XML Schema standard does not mandate a 1-to-1 relationship between a namespace and it’s location. This is probably good and bad. It’s good because, a large open standard that belongs to a given namespace need not be maintained in a single file. However, it is bad because, looking at a given namespace, it’s not possible to figure out which of the multiple files are needed for a given usage. When importing a namespace, it has to be imported multiple times if there are multiple defining that namespace. The standard assumes that beyond the first location, rest all are just as a hint and mandatory. However, Xerces has an option called honour-all-schemaLocations and only when this is set to true (by default it’s false), it will try loading files from all the imports of a given namespace.

In case of OAGIS, all the multiple files belonging to a namespace are put together using include statements and then this single file is imported. This approach would not require the above honor-multiple-schemaLocations fix. But GS1 GDSN has chosen to import multiple files and this took a bit to figure out how to fix the issue.

So, even though modern parsers and tools are capable of recognizing multiple imports, VisualSchema recommends following the OAGIS approach of putting all the namespace files in another file using include statement and then using this single file where needed using an import statement.

VisualSchemas For B2MML

VisualSchema.com has released Visual Schemas for B2MML. This standard has been brought to our attention by Dennis Brandl of BR&L CONSULTING, INC.

After an initial hickup with case mismatch between the schemaLocation field and the actual filename, the generation of Visual Schemas for B2MML went smoothly, except for one thing. B2MML defines Location recursively. VisualSchema can handle recursion. However, it was noted that Visual Schema generated Location -> Location -> “Location add” rather than generating Location -> “Location Add”. In other words, it has generated a location element within a location element while it is supposed to generate only the top level location element. I mean, recognizing recursion shouldn’t require going through two elements, isn’t it?

Unpon examination, it was found that a top level LocationType is defined which makes use of a Location element (which is defined inside this type and hence not a top-level element) that is of type LocationType. Then, in the equipment xsd, a top-level Location element is defined with type LocationType. As a result, the top-level element Location and the inner element Location, while are the same type, are not recognized as one and the same as per XMLSchema semantics. So, Visual Schema has been fixed to detect the recursion not only purely based on the matching element definition objects but also based on the matching of name and type fields. With this fix, only one Location element got created.

To avoid the above situation, the right way of defining the XML Schema definition is to define a top level Type called LocationType along with a top-level element called Location that is of type LocationType and then use this top-level element as a reference in the LocationType definition that uses the Location recursively. Modified the B2MML using this strategy and without the above VisualSchema fix of comparing the name and type fields instead of just the definition objects (object reference comparison) the strategy worked fine.

Visual Schemas For opentravel

opentravel is an open standard for the travel industry. This is perhaps one of the few standards that has two releases a year. It spans the Cruise lines, Hotels, Air, Railways, Insurance, Car Rentals and pretty much everything that touches the travel industry.

VisualSchema is pleased to announce Visual Schemas For opentravel.

XML Schema: Is Extensible Value List A Right Design?

XML Schemas provide precise definition of the XML used to exchange the data. It is possible to have a list of enumerated values for any field. Having such a restricted list of values adds further semantics so that all parties exchanging the documents know exactly what the value means.

VisualSchema had a problem of identifying the list of values for the currency fields in the OAGIS standards. Upon further investigation, it was found that the currency type of OAGIS is actually a Union of two simple types, one with a fixed list of values while the other is a free form.

The pros of this approach is that say a new currency is introduced all of a sudden, it is possible to make the xml documents work with the new currency without having to wait till the standards have been modified. In case of a currency code or any other lov that is based on a ISO standard or other well accepted standards, then one can expect everyone to use the same value with the same semantic meaning. Otherwise, this extra flexibility of being able to adopt immediately to the changes may have incompatibility issues.

VisualSchema has been enhanced to display the enumerations even if it’s also possible to specify any other value.

Visual Schemas For XML Schemas (XSDs)

The specification of XML Schema is quite complex and understanding it to make sense out of the XML Schema of an XML is no easier task. Ofcourse, some XML Schemas are much simpler than the other. However, many real life XML Schemas providing open standards tend to be quite complex. This is understandable because the open standards try to offer the most generic solutions that can hopefully cover all the possible scenarios. Hence, a purchase order document even in the best of the enterprise applications can span only a few dozens of tables, the OAGIS definition has more than two thousand elements (in most cases each element maps to a table when no shortcuts are taken).

VisualSchema.com is a website that provides these complex open standards XML Schemas as easily navigable HTML forms that people are familiar in enterprise applications making it easy even for the non-technical people to understand the XML Schema definitions.

At present, the site provides Visual Schemas for OAGIS and GS1’s GDSN standards.