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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] A practical question on Core components storage, UBL, OAG, etc

Diego,

An interesting approach.  I suppose one could simply rely on the metadata
information to support the search registry function specified in Section 5
of the CCTS. It also supports the notion that CCs/BIEs are designed to
support the work of the process modelers as a means of standardizing their
object names/functions.

I would be curious to know what do you do with the metadata information
once you retrieve it?  Are you dynamically building your own
instantiations of the CC/BIEs from the registry metadata?

Mark


> -----Original Message-----
> From: Diego Ballvé [mailto:diego.ballve@republica.fi]
> Sent: Thursday, April 10, 2003 12:58 AM
> To: Steve Capell; Chiusano Joseph
> 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
> 
> 
> Steve,
> 
> I'm also working on a project that stores CCs using ebXML Registry.
> We've chosen to store the CCs in the registry only, not in the
> repository. I mean there's no XML representation of the CC in the
> registry/repository and the details about the CC are all stored as
> metadata, some as slots, some as associations (from RIM). A reason
> for this approach is, IMHO, the better search capabilities offered
> by the registry for metadata. The approach is currently in use but
> comments/critics are welcome.
> 
> Btw, I remember a discussion about it last week, the result was
> posted to this list in a mail with subject "Re: Mapping of CCTS 1.8
> or 1.9 storage model to ebXML RIM". Unfortunatelly I couldn't find
> the link to the archive to post here.
> 
> Regards,
> Diego
> 
> --------------------------------------------
> Diego Ballve
> Republica Corp., Products
> Survontie 9, 40500 Jyväskylä, Finland
> E-mail: diego.ballve@republica.fi
> GSM: +358 40 301 1140
> http://www.republica.fi/
> http://www.x-fetch.com/
> 
> 
> 
> > -----Original Message-----
> > From: Steve Capell [mailto:steve.capell@redwahoo.com]
> > Sent: Thursday, April 10, 2003 6:09 AM
> > To: 'Chiusano Joseph'
> > 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
> > 
> > 
> > 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
> > 
> > 
> 

<<attachment: winmail.dat>>



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