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