[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of Matters Related to UBL 1.1 Schema Generation
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]