OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [no subject]

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

Two questions:

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

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.

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)
B. in the core *but as CCs* (not BIEs)

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
#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

----- Original Message ----- 
From: <ytlee@cecid.hku.hk>
To: <ubl@lists.oasis-open.org>
Sent: Thursday, May 19, 2005 8:56 AM
Subject: [ubl] Groups - UBL V2.0 Model Architecture (UBL V2.0 Model
Architecture.doc) uploaded

> I updated this document according to the comments received from Yukinori
> Saito. I didn't change every "CCTS" to "ebXML CCTS" because those
> paragraphs were quoted directly from the UBL CD cover note while I added
> "ebXML Core Components Technical Specification" in brackets behind the
> first appearance of "CCTS". I uploaded this document in MS Word format (as
> Mark pointed this out) so that anyone of you can comment on it more
>  -- Mr Thomas Lee
> The document named UBL V2.0 Model Architecture (UBL V2.0 Model
> Architecture.doc) has been submitted by Mr Thomas Lee to the OASIS
> Universal Business Language (UBL) TC document repository.
> Document Description:
> Proposed data model architecture for UBL 2.0
> View Document Details:
> Download Document:
> PLEASE NOTE:  If the above links do not work for you, your email
> may be breaking the link into two pieces.  You may be able to copy and
> the entire link address into the address field of your web browser.
> -OASIS Open Administration

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]