Subject: Prototype of proposed architecure changes
I've just uploaded, to the SSC website
a prototype of how I would envision some
possibilities for changing the spreadsheets
and schemas architectures to fit with the
recent proposals. The package is about
Attached are some notes on this set of
model and schema prototypes.
Please note particularly a point about the
undesirable (in my opinion) affect on
instances if there were a second set of
'core' schemas and my alternative of
renaming the 'common' schemas and
their directory to make them procurement
specific while keeping the proposed
'core' to modeling only / core components.
(If the core components were expressed
in schemas they could, like present CCT
schemas be in schemas which are not
actually imported into and used in other
UBL 2.0 xsd-restructuring-prototype-sdg-9 May 2005 Stephen Green's Notes on this prototype A. directory /mod-spreadsheet-restructuring/ [prototype spreadsheets] 1. No UDT or CCT spreadsheets (ATG2 alignment) 2. Extra 'Version' column (column P) - but this could be replaced with multiple columns to allow more detail / audit trail of version changes (for example, where change has occurred, what was the previous version which changed, is this a new added entity, etc) 3. Core Components added to same spreadsheets as BIEs but with different entry in Component Type column 4. Amended Note for column 'Component Type' to add three types of CC (could change row colours for the CCs but this is not prototyped here) 5. Although the CCs in this prototype have the same names as their respective BIEs, this might need changing. There might be problems having BIEs requiring qualifier terms to distinguish their names from the CCs on which they are based and this might limit the complexity of the package. 6. The 'core' spreadsheet could have both CCs and BIEs (the BIEs based on those CCs, one CC for each BIE) but the protoype demonstrates having just the CCs in the core spreadsheet and having the BIEs in the common spreadsheet(s). This might be determined somewhat by the way qualifiers need to be assigned to the BIEs: that is, if a qualifier is needed for the BIE in addition to the name of the CC and if the qualifier depends on the context then the BIE might have to have two separate qualifiers if it exists in the core spreadsheet as it would then have to be defined again with the further qualifiers in the common spreadsheet(s) too so the context-specific qualifiers can be assigned too. Note too that the BIE qualifiers in addition to the CC names have been left out here. 7. 'Reusable' renamed to 'Procurement' and 'common' directory renamed to 'procurement'. This is to allow further directories / spreadsheets for other domains such as transport. 8. The TBG17 format worksheets have been left out here. If added, there appear to be new formats to use. 9. This demonstration has made the non-core, procurement the BIEs BuyerParty, DespatchLine, etc but a question: if all BIEs have to be based on CCs, how can there be such a thing as a common BIE which does not have a 'core' CC? In that case the CC would be non-core (such as a DespatchLine CC which is specific to procurement) or, more reasonable it seems to me, there might have to be a very generic Line CC as the CC on which to base DespatchLine, OrderLine, etc BIEs but that seems a design problem since the BIEs are quite different. 10. This structure as defined in 6. above has very little difference from the 1.0 structure - just change of name/directory of 'reusable' (no BIEs are moved in this prototype) and addition of new core components spreadsheet. There would need to be further changes such as perhaps qualifiers added to core component naming terms to create the BIE terms and names. Otherwise it might be a manageable departure from 1.0 11. Overall this set of spreadsheets is not intended to be complete and is for illustration of initial basic features for consideration. 12. An extra change here is to split OrderLine and RespondedOrderLine with the latter created as a new common BIE and the former being a restriction of the latter (or both being restrictions/extensions of a CC yet to be defined). This is to illustrate how the models might need to be developed with the spreadsheets. This is not reflected in the schema demonstration. 13. It might help clarity to separate obviously (not particularly demonstrated here) between the BIE and CC rows. However, if CCs are not to be included in schemas (yet?) it might be that a schema generator would just skip CCs wherever they appeared. A human reader would not find this so easy perhaps. 14. Although in this prototype there are CCs defined in common and document spreadsheets, might it not be better to define all CCs in the Core spreadsheet. Then it might be best to call it 'UBL-CoreComponent-2.0' (here it is just called 'UBL-Core-....'). B. directory /with-core-bie-schemas/xsdrt/ [prototype schemas with core bies] 1. Moving elements and types between modules causes namespacechanges in instances and would therefore only be allowed in a major release. 2. The structure illustrated with this prototype has a core directory where BIEs and core components are declared. 3. Modules which had plurals in their names have been made singular (aligns with ATG2 and with much general practise). 4. The schemas for CCs are to illustrate a similar design to the use of schemas to express CCTs even though they are not imported into other modules or used in other declarations. They could be left out of the structure. 5. A real imlementation should probably find a better design for duplication of codelists - both ATG2 and UBL being in use side by side (with potentially different versions of codelists such as currency code). 6. The prefixes have been changed from cac/cbc to pac/pbc to reflect change of name from 'common' to procurement in line with the requirement to separate procurement from other potential domains such as transport. The prefixes have their own prefixes ..2-0 to allow for future minor and major versioning. C. directory /without-core-bie-schemas/xsdrt/ [prototype schemas without core bies] 1. The structure illustrated with this prototype has a core directory but here only CCTS and core components are declared. The BIEs previously called common aggregate and common basic components are placed in a directory 'procurement/' and the modules renamed to allow for other domains to be added in their own directories but sharing the contents of the core and codelist directories. 2. Modules which had plurals in their names have been made singular (aligns with ATG2 and with much general practise). 3. In this design core components could be added without changing existing BIE namespaces. 4. The schemas for CCs are to illustrate a similar design to the use of schemas to express CCTs even though they are not imported into other modules or used in other declarations. They could be left out of the structure. 5. A real imlementation should probably find a better design for duplication of codelists - both ATG2 and UBL being in use side by side (with potentially different versions of codelists such as currency code). 6. The prefixes have been changed from cac/cbc to pac/pbc to reflect change of name from 'common' to procurement in line with the requirement to separate procurement from other potential domains such as transport. The prefixes have their own prefixes ..2-0 to allow for future minor and major versioning. D. directory /without-core-bie-schemas/xml/ 1. Where there are no core bie schemas the instances can be written without requiring specific knowledge of modeling decisions (particularly whether bies are 'core'). E. There are no sample instances for directory /with-core-bie-schemas/ - they would depend for namespaces on the choice between BIEs being placed in either the domain-specific (such as 'procurement') schemas or 'core' schemas and so WOULD BE VERY DIFFICULT TO CREATE and be susceptible to future changes.