Localization and Extension Issues

[Jim Beard <beard@counterclaim.com>]

All,

	I was asked to elaborate on some of the different types of extension
issues and solutions that were used for OXCI.  Below I outlined a basic
GJXDM issue that complicates localizations and described briefly the
different approaches used by OXCI and 2GEFS.


GJXDM Schema Issues - Extension Through Restriction

	Deriving a new XML type can be accomplished through extension or
restriction of another base type.  While it is part of the Schema
Specification, extension through restriction is not a well supported
process.  Many code generation tools and data binding tools do not
fully implement this XML feature.  During OXCI this became a major
issue.  Especially when a type that had been derived previously through
restriction was then extended to create a new type.  This would occur
frequently, as the OXCI types would be created by restriction (since
GJXDM is over-inclusive) then any local data type would attempt to be
defined through extension of the previously restricted type.  Java
tools at the time would not handle this.  Here is a link to an article
by Microsoft, describing .NETs support (or lack) of extension through
restriction.

http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
dv_fxgenref/html/bfc3e797-2228-4f56-a875-31ff73f9c38d.asp

This of course is also one of the main reasons behind using 'subsets'
of GJXDM for any GJXDM-based project.  I do not think that this problem
is likely to go away anytime soon.  Current programming languages in
use today do not support new types being created through restriction,
as it would prohibit (or at least make overly complex) type
substitution.



OXCI Approach

The OXCI approach was to allow for local types to be defined in a
Schema, and for that Schema to be included in the name space of the
instance files, thus allowing them to contain locally defined types.
This of course prevents the instance document from validating
separately against the full GJXDM.  This will likely ensure that
swapping instance documents between different GJXDM-based systems will
not be easily accomplishable.  It would likely require development time
to ensure validation and to ensure proper parsing.


2GEFS Approach

California's Second Generation Electronic Filing Specifications define
a method for creating Schema extensions in the Schema itself.  This is
accomplished by defining flexible code tables.  This allows for an
instance document to validate against the Specification's main Schemas
even if the local implementation contains extensions.  It still
requires local extensions to be discussed and taken into consideration
during integration, however it does not prohibit applications that are
"2GEFS Compliant" from extracting the known data elements defined in
the Specification without requiring development time.  Further
integration and development time is required to extract or use the
extended data sets.


I would recommend that the TC take 1 of 2 approaches.  Either include a
data type in the specification that can be used to contain local
extensions (like 2GEFS has done), or contain all local extension data
(both type definitions and instance document data) in a separate
document.  Either method would likely ensure that Blue would perform at
the same level of 2GEFS in the sense that instance documents would be
able to be validated and data defined by Blue that is not part of the
local extensions could be extracted by any "Blue Compliant" system
without modification.

Jim Beard
counterclaim, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145