[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
450Kb.
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
instance-related schemas.)
Best Regards
Stephen Green
|
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]