RE: [ebxml-dev] A practical question on Core components storage, UBL, OAG, etc

["Steve Capell" <steve.capell@redwahoo.com>]

Joseph,

Thanks for your feedback.  It is not a bad idea to store them both as
CCs and <classify> one as preferred.  

You correctly remind me that CCs are supposed to be syntax neutral but
if I am going to store them in a regsitry then I do need to represent
them somehow.  I don't see any reason to re-invent the UBL convention of
using XSD schema and annotations for the dictionary names.  I'm not
aware of a recommendation from UN/CEFACT on an XML representation of CCs
for storage and reference purposes.  Even if there is one (that is
different to UBL) I don't thing we would bother to re-engineer UBL to
fit at this stage of our pilot project.  Do you think that is a
reasonable position?

Regards,

Steve Capell
RedWahoo
Sydney, Australia
Tel : +61 410 437854


-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: Thursday, 10 April 2003 12:49 PM
To: Steve Capell
Cc: 'Ebxml-Dev@Lists. Ebxml. Org'; ubl@lists.oasis-open.org
Subject: Re: [ebxml-dev] A practical question on Core components
storage, UBL, OAG, etc


Hi Steve,

Great questions. Please see comments below:

<Quote1>
1       Should we store both the UBL <Address> and OAG
<PostalAddressBase> as aggregate core components - they are both context
neutral re-usable components and so are candidates to become standard
aggregate core components.  The problam is that they are different in
both syntax and semantics.  Is it better accept duplication and make
them both core components - or to pick one as our reference "address
core components" and make the other an ABIE with a context of "legacy
standard compatibility"?  
</Quote1>

You could store both (keeping in mind that Core Components are
syntax-neutral). If you have a business/technical need to "classify" one
(using term in general sense) as your "primary" or "preferred"
representation (perhaps based on which is more frequently used given
your trading partner interactions), then that sounds like a good idea.
If you had several, you could certainly assign a preference to each
(simply a non-contiguous integer value, to keep it simple).

<Quote2>
2       If, for example, we pick UBL as our reference core component
then we need to be able to map the OAGIS address block back to the UBL
address block via a context driver.  The problem is that OAG uses a
repeating <addressLine> element whilst UBL explicitly defines <Street>,
<HouseNumber>, etc - so there is no match at BCC <-> BCC level.  The way
to make a match is to add a new element to UBL which is a repeating
<AddressLine> - but then there would be duplication within the UBL
address reusable component.  
</Quote2>

In my opinion, not having a match at the BCC <-> BCC level is ok (that
is probably going to be the case more often than not, with multiple
transaction vocabularies existing in the world). You could map OAG's
<addressLine>[1] (i.e. first occurrence of addressLine element - this is
my own notation, not a standard) to UBL's <Street>, <addressLine>[2] to
UBL's <HouseNumber>, etc. I think this would be better than adding the
new element to UBL as you mention - this approach (adding new element)
seems like it is "forcing" a new element for technical purposes, rather
than including it for business purposes. 

<Quote3>
Is it a REQUIREMENT of the CCTS that BBIE elements must map to a
corresponding BCC element? </Quote3>

I think this may be a moot point based on my response to <Quote2>, but:
Since a BBIE is a BCC used in a specific business context - i.e. a BBIE
is "derived" from a BCC - I would say definitely yes. 

Hope that helps,
Joe Chiusano
Booz | Allen | Hamilton

Steve Capell wrote:
> 
> Hello all,
> 
> We are in the process of defining a storage model for an Australian 
> repository of standards.  The CCTS v1.9 provides a very detailed model
> but:
> 1       It does not map directly to ebXML RIM (I know that there is a
> project underway to do this).
> 2       It would be very time consuming to populate a regsitry to the
> level of detail defined in CCTS1.9 without some tools to transform UML

> model <-> XSD schema <-> Registry Meta-data.
> 3       It is difficult to accommodate existing standard libraries
like
> OAG 8.0 that does not align with CCTS (I know that OAG 8.1 beta 
> presents an initial alignment but it is not yet in common use..).
> 4       CCTS1.9 provided a currently approved list of core components
> types but not yet any definitions of basic core components or 
> aggregate core components.
> 
> So we have decided, for the time being, to simplify the storage model.

> Some immediate practical questions are:
> 1       Should we store both the UBL <Address> and OAG
> <PostalAddressBase> as aggregate core components - they are both 
> context neutral re-usable components and so are candidates to become 
> standard aggregate core components.  The problam is that they are 
> different in both syntax and semantics.  Is it better accept 
> duplication and make them both core components - or to pick one as our

> reference "address core components" and make the other an ABIE with a 
> context of "legacy standard compatibility"?
> 2       If, for example, we pick UBL as our reference core component
> then we need to be able to map the OAGIS address block back to the UBL

> address block via a context driver.  The problem is that OAG uses a 
> repeating <addressLine> element whilst UBL explicitly defines 
> <Street>, <HouseNumber>, etc - so there is no match at BCC <-> BCC 
> level.  The way to make a match is to add a new element to UBL which 
> is a repeating <AddressLine> - but then there would be duplication 
> within the UBL address reusable component.  Is it a REQUIREMENT of the

> CCTS that BBIE elements must map to a corresponding BCC element?
> 
> My gut feeling is that if we don't start to build a library of 
> non-duplicated reference core components then there is little point 
> building a library at all - we may as well just publish the separate 
> libraries as they are today.  This implies to me that we will probably

> only be able to go down to the resolution of reusable component like 
> <Address> in terms of relating standards like HL7, EANCOM, etc back to

> the reference core component library.
> 
> Any gems of wisdom, comments, answers, etc on this issue will be 
> appreciated.
> 
> Regards,
> 
> Steve Capell
> RedWahoo
> Sydney, Australia
> Tel : +61 410 437854