Re: [ubl] Groups - UBL V2.0 Model Architecture (UBL V2.0 ModelArchitecture.doc) uploaded

["Thomas Y.T. Lee" <ytlee@cecid.hku.hk>]

Hi Stephen,

 Thanks for valuable comments. Here are my responses to your questions according to what I understand on
the discussion in the plenary meeting.

> Such change might not have much impact on tools
> so I'd be all for it, even at this stage (yet to ask SSC
> though). I expect time would be taken to create the
> 'CommonTransport' spreadsheet and then to decide
> on what is 'core' (I hope it would be with a view
> to comparison with TBG17 CCs to broaden the
> scope beyond just procurement and transport). In
> that time we might hope to decide how to represent
> these CCs in the schemas and how to base BIEs
> declared in schemas on them (through XSD derivation
> based on the CCs or just as declarations as now but with
> references to the underlying CCs in XSD documentation
> or even some other way).
>
> In the meantime, I'd imagine we'd need small changes
> to the schema design to rename the CommonAggregate
> Components and CommonBasicComponents to something
> with Procurement in the name (still splitting aggregates
> and basics?). Maybe we'd be adding Transport before
> 2.0 and therefore need schema modules with Transport
> in the name too. All this seems like small changes to
> me.

 You're right. The impact might not be large while we would like to let the
NDR team decide whether they want to change the schema architecture in
response to potential change the model architecture.
 You can see this way the proposed architecture just suggests to
redistribute the model components from two layers of spreadsheets to three
layers of spreadsheets so that the components are grouped in more logical
context-based modules.

> Two questions:
>
> 1. Would we be seeking to either a) combine BBIEs
> and ABIEs in the same schemas?

 There was a discussion in the meeting on whether there is an advantage to
separate BBIEs and ABIEs into two schemas while the users had to import both
schemas anyway in most occasions. The question on whether BBIEs and ABIEs
(in the same class e.g. Common Procurement BIEs) should be combined in one
schema (e.g. Common Procurement Schema) in future. There was no specific
conclusion but letting the NDR decide.

2. Would we be adding individual BBIEs to the
> common and core spreadsheets (outside of ABIEs,
> that is document level BBIEs which are considered
> reusable or rather potentially 'common' or 'core'?

> These would require, at a guess, more substantive
> changes to tools for schema generation and perhaps
> also to implementation software but it might still
> be the time to consider it.

 Yes, the individual BBIEs are very likely placed in the common or core
spreadsheets because they are created for the purpose of reuse. The
potential changes on the tools are possible.

> A third question:
>
> 3. What timescale might all this happen over?
>
> I hope that the design would be that only CCs
> exist in the 'core' spreadsheet(s) and schema(s).
> Then the BIEs would all be in the 'common'
> files and new namespaces wouldn't be needed
> when something moves to 'core' since its BIEs
> wuld still be where they started and the instances
> would then be protected from changes. The main
> reason (apart from that it seems to me the way
> to implement CCTS) is that then CCs could be
> created and improved without the need for a
> new major release and so could be created
> more quickly than if we had to wait the time
> our user base would prefer there to be between
> major releases.
>
> Plus I think it is the case that we need all BIEs
> to be based on CCs so *all* BIEs should be
> declared *both* in
> A. either a document spreadsheet (and schema module) or
> common spreadsheet (and schema module)
> *and*
> B. in the core *but as CCs* (not BIEs)

  It is a fair argument that this architecture doesn't address the
requirement on the use of CCs while it is direcly derived from the current
model architecture that treats CCs as all-context BIEs. However, when we
think more deeply, the Core BIEs are the potential CCs we may want to
create. IMHO, this architecture is more easily to be extended to cover the
CC requirement.
  In fact, Saito San of the JPLSC has taken a task to try out the concept by
reorganizing the existing BIEs into the three layers of spreadsheets. I
believe Saito San's analysis will be a good base for us to identify CCs
from.
 Stephen, your input exactly addresses the possible extension of the
architecture while a discussion is yet to be made whether to create CCs for
every BIEs in the UBL library to base upon.

Cheers, Thomas

> ****
> I think we can do this from day one and refine the
> CCs as we compare them with Transport BIEs
> and with TBG17 CCs (if that is still on the cards).
> We'd need decisions:
> #1. on how to represent the CCs in schemas
> (presumably a separate schema module(s) for core
> but whether to use derivation to base the BIEs on the
> CCs)
> #2. whether to add, for now, initial CCs to the
> 'CommonProcurementComponent' and
> (perhaps later as we progress) the
> 'CommonTransportComponent' spreadsheets
> and perhaps to the 'common...' schemas
> (perhaps we'd call them candidate CCs but
> have them expressed just to avoid having BIEs
> which aren't based visibly on CCs)
> with a view to moving them (without impacting
> on instances, hopefully, and hence in minor
> releases) to 'core' files over time.
> #3. how to say in the model which CC a BIE
> is based on (perhaps a CC in the same
> spreadsheet or perhaps one in another)
> #4. how to name a CC while avoiding name
> clashes with equivalent BIEs
> ***
>
> - Just my initial thoughts
>
> All the best
>
> Stephen Green
>