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

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