Mark, We are generating XMLSchema dinamically. Assembly documents are built by making queries to CC/BIEs (metadata). XMLSchema (what we actually need) is then generated automatically. This way we abstract the representation (xml, in our case) from the model (CCTS). I guess that is the original idea. The process as a whole still needs work. As I understand we are leaning towards the bindings approach for storing CC/BIEs although we do have to refine it (for instance, manipulate CC/BIEs through binding classes and not to manipulate ExtrinsObjects/Slots/Associations directly, which I have plans to do soon). The idea has always been to stick to the (developing) specs but we've had to make decisions in order to model forms asap. I hope we are going in the right direction. Regards, Diego > -----Original Message----- > From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org] > Sent: Thursday, April 10, 2003 2:00 PM > To: Ebxml-Dev@Lists. Ebxml. Org; ubl@lists.oasis-open.org > Subject: 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>>