[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Localization and Extension Issues
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]