Minutes of UBL Software SubCommittee Call 3rd Mar 2005

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

MINUTES OF THE UBL SOFTWARE SUBCOMMITTEE 3rd MAR 2005

Those attending: Tony Coates, David Kruppke, Stephen Green 
Apologies: Anne Hendry, Sylvia Webb

There was considerable discussion regarding three main issues:
1. Import / Derivation for UBL 1.1
2. NDR 1.1 Changes
3. Schema generation

These are summarised below:

1. Import / Derivation for UBL 1.1

There were comments made that there might be other ways to 
regard backwards compatibility which went beyond that concept
provided for in the W3C Schema (XSD) derivation methodology 
and that there might also be other ways to cater for versioning.
However, it was pointed out that the UBL 1.1 NDR mainly
catered for the XSD derivation mechanism and the associated
method for allowing use of multiple versions and that this was
very much integral to the design of UBL.

With regard to the issue raised by email 
(see http://lists.oasis-open.org/archives/ubl/200503/msg00001.html )
about there being a need in 1.1 for the use of an prefix which had 
not been required on certain elements in 1.0-valid instances, it was 
pointed out by David that there would also be the need for the new 
namespaces in instances for them to be valid against 1.1 Schemas so 
the extra prefix wouldn't be less of an issue. A 1.0 instance would not 
be valid against the 1.1 Schemas unless its namespaces were changed 
of course and so to have to add a prefix too to all the locally declared
Document Schema level BBIEs would not pose much more of a 
burden. The fact that the 1.1 Schemas conformed to the XSD
derivation mechanism correctly would be sufficient to determine
(by definition really) backwards compatibility of the 1.1 instances.

The use of imports, it was agreed, would be necessary, even with
the Document Schemas, to provide a guarantee that nothing in the
previous release Schemas had been changed before the use of the
derivation mechanism.

(XSD:include cannot be used because for xsd:include to work the
included Schema has to have the same namespace as the including
Schema.)

_____________________________________________________
In conclusion, no change would be necessary to Naming and Design
rules VER8 and VER9 (rules concerning use of derivation in minor
releases).
_____________________________________________________


Furthermore, there would NOT be a necessity to change the name of
a Type which derived from a previous release Type since the distinction
would be made in the namespaces (though the NDR points out that a 
change of Type name is an option if desired).

(see also "WithDocumentSchemaImport-prototype-3" in illustration 
package at http://lists.oasis-open.org/archives/ubl/200503/zip00000.zip)


2. NDR 1.1 Changes

David made the following points for reference back to NDR:


-------------------------------------------------------------------------------------
a) 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. This duplcation
seems undesirable.

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


Otherwise there were no problems (as yet) with the list of changes
asked for in message
http://lists.oasis-open.org/archives/ubl/200502/msg00056.html


3. Schema Generation

The requirements for the tool were discussed and it was felt that
development should allow certain freedom for the developer(s) to
engineer the tool as they saw fit. 

_____________________________________________________
It was 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.
_____________________________________________________


Tony pointed out, however, that this overall design might limit
modeling beyond the limits of the XSD backwards compatibility
concept and that it might be a requirement to add, for example,
the facility to restrict cardinality (perhaps needing use of rows
in the spreadsheet rather than columns since columns would
be less scalable with the need to add a column for every new
minor version). 

David's reservations were about just limiting the tool to the
XSD backwards compatibility concept in that (as defined in the
NDR) semantic backwards compatibility also had to be preserved
and this might mean limiting restriction facilities beyond the limits
of what is allowed in XSD import/derivation rules. 

Stephen pointed out that restriction would be necessary when 
the modelers wished to reuse a Type in a different message, not 
wishing to allow the use of all of its BBIEs and ASBIEs. This would
not break backwards compatibility since it would involve the creation
of a new and therefore previously non-existent Type.



The meeting was ended after approximately 2 hours.