Case that we can avoid substitutionGroups now without precluding them for later

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Case that we can avoid substitutionGroups now without precluding them for later

 

Please find attached a proof of concept set of Schemas

 

This uses the latest Schemas from Gefeg (1.0 draft 8.1) as a strarting point

 

I have added two different versions of the currency codelist schema

- UBL-CodeList-CurrencyCode-1.0-draft-8.1sdg.xsd   - this has no substitutionGroups and represents what we could start with now

- UBL-CodeList-CurrencyCode-1.0-draft-8.1substitutionGroup.xsd - this has substitutionGroups and represents what Marty is proposing but which I propose deciding about say prior to UBL 1.1

 

UBL-CodeList-CurrencyCode-1.0-draft-8.1substitutionGroup.xsd   slightly differs from Marty's in that it has the sequence of Supplementary Components we have in draft 8.1

and uses DerivedCode and DerivedCodeType as names. It also has amended namespaces. Yet I believe it does not differ substantially (functionally) from the CLSC version.

 

To use each of the above the name should be changed of either to UBL-CodeList-CurrencyCode-1.0-draft-8.1.xsd but that is all.

 

There are also included two samples of an invoice, generated with XML Spy 2004 as maximal examples from each of the two possible sets of Schemas and named accordingly.

 

Proof:

It is found that *each* instance validates correctly against *each* Schema set version/configuration. There is therfore both backwards and forwards compatibilty

when switching from our present draft 8.1 (without substitutionGroups) to a version

as proposed by CLSC *with* substitutionGroups.

 

Conclusion:

It would be, I propose, completely feasible to leave the codelist schemas without the S'Groups now for 1.0 and to defer a decision till between 1.0 and 1.1

There would be a requirement to create a Codelist Schema Module for each codelist

for which we might wish to leave room for s'Groups later (if agreed) but to create in the

present format *without* s'Groups now knowing that we can change it later. It would for many codelists now be empty (as with our beta).

This would avoid our current situation of lack of time for all to consider this thoroughly and to be happy with the CLSC proposal.

(It might be noted that non-codelist enumeration lists could be kept in the SDT and not

have codelist schema modules, thereby allowing these to avoid the possibility of future

encouragement to change them - i.e. changes to such would require namespace changes too.) 

 

Thanks

 

Stephen Green

 

Steves Proof of Concept 1.0 draft 8-1.zip