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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

[Bringing OASIS/ebXML Registry TC into the loop. Topic is XML
representation of Core Components.]

Steve,

I should mention that I am not on the UBL listserv copied on this e-mail
(I am on the UBL LCSC listserv), so please feel free to forward my
replies to that listserv if you would like to have potential feedback on
them from UBL.

<Quote1>
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.  
</Quote1>

Absolutely. There has been some work done in the past (exact status
unknown to me) by David Webber, called CRI (Component Registry
Interface). This began under UN/CEFACT as part of a subteam called CCR
(Core Component Realisation). We (the Registry TC) are still considering
whether or not a serialization format for Core Components should be
defined vs. having all metadata in the RIM (through a binding) and
having Core Components be represented as "XML fragments" (such as an
Address ABIE). We are going to be discussin CRI in the coming weeks, and
how it may fit into the overall picture.

<Quote2>
I'm not aware of a recommendation from UN/CEFACT on an XML
representation of CCs for storage and reference purposes. 
</Quote2>

The closest UN/CEFACT came to this was the CCR/CRI work referenced
above. There is a group under UN/CEFACT (called ATG) that is working on
defining what I term a "Core Component Instantiation", which is
different from a Core Component serialization (what you see in the UBL
instance documents will give you an idea of this group's work). They are
in the very early stages, and will be doing more work in London at the
end of this month.

<Quote3>
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?
</Quote3>

Very reasonable.  

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

Steve Capell wrote:
> 
> 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
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard