Summary of Matters Related to UBL 1.1 Schema Generation

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

UBL TC

Greetings

An action item given me at the last Atlantic meeting was
to summarise the previous mails I sent regarding Change
Requirements for Schema Generation and the NDR Import
and Derivation Rules VER8 and VER9 and to update these
following their discussion in the Software SC call on 3 March.
Refs:
 http://lists.oasis-open.org/archives/ubl/200502/msg00056.html
 http://lists.oasis-open.org/archives/ubl/200503/msg00001.html
 http://lists.oasis-open.org/archives/ubl/200503/msg00005.html
 http://lists.oasis-open.org/archives/ubl-ssc/200503/msg00006.html


1. IMPORT / DERIVATION IN UBL 1.1

The rules VER8 and VER9, SSC concluded, are good to 
implement as they are, provided it is understood that they
introduce a particular form of backwards compatibility which
is that produced by conformance to the W3C Schema
derivation methodology (as incorporated into the UBL
Customisation Methodology). This is of course clear
in the NDR document.

Two points of note emerged from the SSC meeting:

a)    The use of xsd:import with Document Schemas is
       valuable in that it ensures that the previous version
       Document Schemas are unchanged before their use
       as a basis for the Types in the importing Document
       Schemas. However, there is then a side affect in that
       some BBIE elements which are declared locally in the
       Document (Identifiers, such as ID, and Codes) then
       require a prefix whereas they don't in the major release. 
      * This has been regarded as acceptable since there would 
       need to be other textual changes too (to namespaces 
       and Schema locations) to a major release instance
       before it would be valid against the minor release Schemas.

b)    Further concepts of backwards compatibility concerning 
       semantic content of messages and Types are also 
       included in the NDR. These would be modeling issues but
       it is feasible that the tool might seek to cater for these in 
       some way, perhaps during Schema generation.
       


2. QUERIES / COMMENTS

A list of NDR-related comments/queries was sent to the ubl list on Feb 28th.

In summary:

a)     The following changed rules might break backwards compatibility 
        and if so should they be excluded from 1.1?  
          GNR10   GNR11   ATN2

b)      Rules CTD10 and CTD12 require clarification with regard to the
         Schema changes they require.

c)      Further NDRules are required to cover details of VER8 and VER9
         implementation such as:

   i) - a rule for the the prefix naming convention to be used for imported 
       Schema namespaces
   ii) - clarification of the methods for documentation when derivation is 
       involved
   iii) - an update to rule GXS1 to cover the extra imports, the new derived 
       complexTypes
  iv)  - necessary use of xsi:type in instances

SSC would add the following:

d)     Rule DOC9 and an aspect of DOC8 seem to require a repeat of
        all the values of a codelist in documentation even though they already
        would exist as enumerations in the codelist Schema. Is this intended?

e)     Alphabetic ordering of the codelist Schemas' references should
        be added to GXS1
    


3. SCHEMA GENERATION AND MODELING

With regard to Schema generation, SSC concluded that, were the 
Edifix tool to be used for 1.1 Schema generation, it would probably 
require both sets of spreadsheets (1.0 and 1.1 or later version equivalents) 
to be imported for Schema generation and that there should be an extra 
column in the minor version spreadsheet for a flagging of the version 
number of the BIE.

Other aspects of derivation should be considered for spreadsheet
design and Schema generation such as:

a)   How much restriction to allow in view of the need for backwards
      compatibility not only with xsd derivation but also with modeling
      practise related to semantics of content

b)   How to cater for restriction of cardinality

c)   XSD Derivation adds a second means by which to reuse BIEs,
      the first being that previously possible using just the model.
      For example, the Party ABIE was already reused in 1.0 and
      extended in the BuyerParty ABIE; now the modelers can 
      reuse and extend or restrict the Party ABIE as a further 
      qualified Party either by just creating a new ABIE in 1.1 and
      basing it in the model on the ABIE Party by declaring it as an
      Associated Object Class and adding it along with other BIEs
      to a completely new ABIE (e.g. calling it FactoringParty) or
      by flagging it as being an XSD derivation of the 1.0 Party
      (perhaps still renaming it as FactoringParty). The latter adds
      the possibility of resticting it in the process. Should these
      two methods be kept separate and treated differently by
      the tool (the second leading to XSd derivation but not the first)?


4. OTHER COMMENTS

A personal comment on future UBL model and Schema modularity:

I would add that I would consider it particularly useful at some stage
in UBL's future to have separate ABIEs derived from reusable ABIEs
(at least in some cases of ABIEs) for each of the UBL documents.
Two example:
Delivery - here it would seem advantageous that Invoice have its
own specialization of Delivery, based on the reusable 1.0 Delivery,
not including the date BBIEs which only apply to Order or to
DespatchAdvice.
LineItem - here I would like to see OrderLine not having to include those
ASBIEs which really only seem to apply to OrderResponse (perhaps to
OrderChange too) when included in an Order Document
In both cases the chance to restrict these complexTypes differently
in different documents in a future release of UBL 1.x (or 2.x) would
seem to me an opportunity well worth taking.
This though would mean a significant impact on the design of the tool
and probably, I think, a change to the existing design of Schema
modularity.



Many thanks to David Kruppke and Tony Coates for discussing many
of these points on the SSC call and to the TC for receiving these
remarks.



Stephen Green