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: Re: [ubl] Groups - UBL V2.0 Model Architecture (UBL V2.0 Model Architecture.doc) uploaded


Mark

Just one thing that always puzzles me with this approach:

> UBL should be defining BIEs based on
> existing core components, or where no existing core components exist, on
> candidate core components. As context specific BIEs are created in
> different functional areas (transport, procurement, customs and so on),
> those BIEs must go through a harmonization and approval process such as
> what TBG17 does.

How does one base BIEs on CCs or candidate CCs
if you need a harmonization and approval process
with them to create the CCs? This seems an
impossibility to me.
Should we:
1. first create BIEs then use them to design CCs on which
they can be based   or
2. first create the CCs then derive the BIEs from the CCs?

Secondly, do the CCs ever need to be expressed as CCs
in the schemas?
If not then we have to derive BIEs from them in the model
only and not use XSD derivation to base BIEs on CCs in
the schemas.
If we do have CCs as CCs in the schemas, should we use
XSD derivation to derive the BIEs from them?

There are a few other things which always puzzle me about
the CCTS but this will do for now :-)

All the best

Steve


----- Original Message ----- 
From: <MCRAWFORD@lmi.org>
To: <ubl@lists.oasis-open.org>
Sent: Friday, May 20, 2005 3:24 PM
Subject: RE: [ubl] Groups - UBL V2.0 Model Architecture (UBL V2.0 Model
Architecture.doc) uploaded


Stephen,

There seems to be a misconception regarding the role of core components.
Core components provide a conceptual model.  BIEs provide a
physical/logical model.  Core Components are used as reference points in
harmonizing BIE creation/submission.  They are never instantiated in
information exchanges.  BIEs are all derived directly from core
components - not from other BIEs.  UBL should be defining BIEs based on
existing core components, or where no existing core components exist, on
candidate core components. As context specific BIEs are created in
different functional areas (transport, procurement, customs and so on),
those BIEs must go through a harmonization and approval process such as
what TBG17 does.  In my opinion, the proposed V2.0 model architecture is
overly ambitious given the lack of any relationship to existing core
components, agreement to develop candidate core components, or
harmonization process across the multiple functional areas.  I am deeply
concerned that we are putting ourselves on a path that will result in
significant interoperability problems downstream.

Notwithstanding the forgoing, I see absolutely no reason why the current
modularity model requires changing.  We created the concept of internal
schema to handle document/functional area specific types.  Everything
else goes in the common reusables.

Mark
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, Representative
Vice Chair - OASIS UBL TC, UN/CEFACT Applied Technologies Group
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components


LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The opportunity to make a difference has never been greater.

www.lmi.org


> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> Sent: Friday, May 20, 2005 7:21 AM
> To: ubl@lists.oasis-open.org
> Subject: Re: [ubl] Groups - UBL V2.0 Model Architecture (UBL
> V2.0 Model Architecture.doc) uploaded
>
> Congratulations to Thomas on this excellent proposal and
> potential solution to some pressing problems (not least of
> which being how to design Core Components).
>
> From a tools perspective it is encouraging to me to consider
> that for the immediate future, until the addition of the
> Transport components allows some consideration of what might
> be 'core', I think that all we need initially do is rename
> the 'Reusable'
> spreadsheet we have in 1.0 to 'CommonProcurement'
> or the like. However (see the end paragraph below) it might
> not be quite so simple but I'd want to try to keep to just
> this change at the very start in case we need to delay
> further changes until after 2.0 in case we need to avoid
> delaying the release.
>
> 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.
>
> 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)
> *and*
> 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
> 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
>
>
>
> ----- 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
> easily.
> >
> >  -- 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:
> >
> http://www.oasis-open.org/apps/org/workgroup/ubl/document.php?
> document_id=12776
> >
> > Download Document:
> >
> http://www.oasis-open.org/apps/org/workgroup/ubl/download.php/
> 12776/UBL%20V2.0%20Model%20Architecture.doc
> >
> >
> > PLEASE NOTE:  If the above links do not work for you, your email
> application
> > may be breaking the link into two pieces.  You may be able
> to copy and
> paste
> > the entire link address into the address field of your web browser.
> >
> > -OASIS Open Administration
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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