#OAGIS X reviewed - part 2

This is part two of a review of OAGIS X release candidate 1 from OAGi.  (twitter: @OAGi_Standards)  See review part one.

One of the interesting aspects of this release is around extensions.  The 2 main extension methods you've seen in previous releases are still there.  The <UserArea> element is still ubiquitous.  And it is by design the last element in a content model in all cases except where there is a type derivation.  This handy element has been one of the mainstays of working with a standard in the real world of sometimes messy and custom data.  Secondly, the elements in release X are still almost all globally scoped.  This enables one to use the substitutionGroup extension method that is also common and goes back to version 8 of OAGIS.

What is different about this release is that it makes management of extensions easier rather than employing some new engineering gadget.  Very practical.  To begin, there is an Extensions.xsd file which centralizes your extension management.  This file is the link between custom and standard content models.  It is where the UserArea global element is defined.  But there are changes from there.  The UserArea is defined as "AllUserAreaType".  This type is a convenince yet again as it extends the "OpenUserAreaType" (see below) with a sequence that ships as empty.  So one can simply add in elements to this sequence and instantly have widely impacted additions to the UserArea content model.  Nice.

    <xsd:element name="UserArea" type="AllUserAreaType"/>

    <xsd:complexType name="AllUserAreaType">
        <xsd:complexContent>
            <xsd:extension base="OpenUserAreaType">
                <xsd:sequence><!-- easy to insert extensions here --></xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

Next, as mentioned, there is the OpenUserAreaType.  This takes the most commonly used extension elements and puts them explicitly in the UserArea.  Things like name value pairings, codes, IDs, and text can all be used out of the box here.  They will look familiar to folks working with CCTS Representation Terms and the  UN/CEFACT Core Components Data Type Catalogue. In all my years of experience, I've found these kinds of elements in the OpenUserAreaType to be the most often used in a pinch.  So again the management is easy.

Lastly, there is the AnyUserAreaType which is an xsd:any with strict process contents.  This is how the UserArea used to be defined in previous releases.  In this release, it is a type that can be employed as needed.  In fact the UserAreaType is one of these "any" definitions.  However it is important to note that the UserArea global element is not defined as "UserAreaType" but as "AllUserAreaType" which extends "OpenUserAreaType".  So be sure to keep that straight and you'll have lots of possibilities for managing extensions at your fingertips.