[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
Kind Regards, Joe Chiusano Booz | Allen | Hamilton OASIS/ebXML Registry TC Chair, Core Components Review Subcommittee Diego Ballvé wrote: > > Hi Joe, > > I understand your point. You do need something concrete out of > the CC/BIE model you create. In our case, we need XMLSchema. > Although, we want the model to be reusable and not tied to XML, > and that's why we use an extra phase to build the Schema. > > If you are interested in the model we are using (on top of RIM), > it is probably an early implementation of the bindings approach. > The basic idea is: > - Concepts for BCC(Candidate), ACC(Candidate), CCT, ABIE, BBIE. > (We're now creating CC Candidates. If the specs get to define > a CC list then we'll probably try to bind our library to it) > - ExtrinsicObjects of type CCT for the CCTs defined by the specs > - ExtrinsicObjects for Aggregate CCs with slots containing > details that are in the XML Schema annotations and (Contains) > associations to BCCs > - ExtrinsicObjects for Basic CCs with slots containing > details that are in the XML Schema annotations (UBL Excel) > and (Extends) associations to CCTs > - ExtrinsicObjects for Aggregate and Basic BIEs with (Extends) > associations to corresponding CCs and Classifications for > contexts. > > With that model and a few rules we're able to generate XMLSchema > fragments and then combine them into the desired schema. > > Consider also that some modelling has been made using (customized) > UBL Excel sheets. In order to upload that to the registry, we've > implemented an extracting tool that will build the correspondant > model for each sheet and feed it into the registry. Now the goal > is that our modellers will be creating CCs directly into the > registry. > > Regards, > Diego > > > -----Original Message----- > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > Sent: Thursday, April 10, 2003 1:58 PM > > To: Diego Ballvé > > Cc: Steve Capell; 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 Diego, > > > > Thank you for your thoughts. This all depends on what one > > wants/needs to > > do with the information that Core Components represent. For > > example, if > > you have an "Address" ACC (Aggregate Core Component) > > registered that is > > great - but what do you need to do with it from that point on? If you > > need to use it to represent an Address in an XML document > > (perhaps with > > business semantics/context, such as "Shipper Address"), then of course > > there would need to be an XML representation of the Address > > ACC "known" > > to the registry somehow (whether it is stored in a local > > repository, or > > referenced elsewhere). > > > > But since Core Components are syntax neutral, you could just as well > > substitute X12 EDI, flat file representation, EDIFACT MIG, > > etc. for XML > > in the above statements. > > > > Regarding the discussion you mention on "Re: Mapping of CCTS 1.8 > > or 1.9 storage model to ebXML RIM": I have had technical issues in the > > past with locating archived messages, so I've reproduced the main > > posting in this thread for you below. Hope it helps. > > > > Kind Regards, > > Joe Chiusano > > Booz | Allen | Hamilton > > OASIS/ebXML Registry TC > > Chair, Core Components Review Subcommittee > > > > <EMail> > > Steve, > > > > Thank you for your interest and the work that you are doing. I > > personally commend you on your deep understanding of both the ebXML > > Registry specs and the CCTS spec. > > > > You e-mailed me privately last evening (my US Eastern time), > > and I have > > not had an opportunity to respond to you until now. I would like to > > respond to you here, one item at a time. > > > > <Quote1> > > The way I see it there are a couple of options: > > 1 The very simple approach just puts most of the actual data in > > the repository object (in some XML format - probably according to UBL > > guidelines). > > </Quote2> > > > > Upfront Note: Any references here to "Core Components" should be > > interpreted as "Core Components and their associated entities (BIEs, > > etc.) > > > > The approach you reference is what I call an "XML serialization" > > approach, in which the metadata for a Core Component (and its > > associated > > entities) is stored as a "wrapper" with the Core Component. > > That indeed > > is the simplest approach, and it makes it easy to transfer a Core > > Component from one registry to another because the metadata > > "goes along > > with it". There are, however distinct disadvantages - one > > being that any > > change in metadata representation requires a change - not in the > > registry through slots - but to the application that creates > > (and those > > that interpret) the serialized Core Component. > > > > Also, the convenience of transfer that I reference above becomes > > somewhat of a moot point with v3, as this capability is > > covered as part > > of the Cooperating Registries feature. > > > > I can tell you that in the Registry TC, we are leaning heavily *away* > > from the XML serialization approach. That is, we are leaning heavily > > *toward* specifying all of the metadata in ebRIM (through a binding - > > more info below), and *none* of it with the Core Component. > > > > <Quote2> > > At RIM level there is just a simple "extrinsic object" > > entry for each CC and ACC with limitd meta data and no associations. > > </Quote2> > > > > Correct - but as you know the model is extensible; that is, > > you can use > > Slots to add whatever attributes you need. You can also create the > > associations you need using the Association Types included in > > the ebRIM. > > There should be a sufficient amount/variety to cover most needs. > > > > <Quote3> > > 2 The more complex approach attempts to map the CCTS meta-model to > > the RIM meta-model so that there is only the basic XML > > serialisation in > > the repository and most of the meta-data is maintained as registry > > objects (associations, extrinisc opbjects, etc, etc). > > </Quote3> > > > > (I now note that you also use the term XML serialisation > > here, which is > > great!) > > > > Yes - that is absolutely correct. That is what I term the "exclusively > > metadata" approach (I also call it "hardcoding" the metadata into > > ebRIM). We (the Registry TC) have pretty much decided against that > > approach, as the RIM is designed to be extensible and should therefore > > be used as such. We are leaning toward creating a "binding" for ebRIM > > that will utilize the existing model and the abstract/extensibility > > mechanisms (i.e. extrinsic objects and slots). I foresee that this > > binding will *not* be tied to a specific ebXML Registry version - that > > is, most likely you will not have to wait for another > > version. Instead, > > the binding definition will most likely be released in > > between versions > > 3 and 4 (exact timeframe TBD, as I've mentioned previously). > > > > <Quote4> > > The second one is harder to do but give the advantage that useful > > queries can be constructed on registry meta data. > > </Quote4> > > > > Yes - in other words, with the XML serialization approach, one must > > "delve into the stored Core Component" for all or part of the query > > matching. There are advantages and disadvantages to this approach. > > > > <Quote5> > > This argument continues all the way up the chain from CC to BIE to > > reusable XML components, to aggregate business document, to process > > definitions that embed the documents. It boils down to > > whether I want to > > get intelligent data out of the registry or whether I am just going to > > use it as dumb storage. Ie - if I want to know all business documents > > that leverage a particular CC or BIE then I can issue a > > simple query if > > there is rich meta-data. If not then I have to have some external > > application that downloads all business documents and examines the > > contents for relationships to BIEs etc - probably an impractical > > proposition. > > </Quote5> > > > > Yes - it is *highly likely* that in the future, business process > > definitions (and other business-related entities) may be handled the > > same way - through the creation of an ebRIM binding, rather than > > "hardcoding" the metadata into ebRIM. > > > > You also asked in this e-mail about CCBP - that is not under > > the purview > > of the Core Components Review subcommittee, but perhaps something that > > the Registry TC should think about for the future. It is now on our > > radar screen for (at a minimum) discussion - thank you for mentioning > > it. > > > > <Quote6> > > In my opinion, the value of ebXML RIM is that it provides an > > architecture to support complex data models and consequently > > provide for > > useful information at registry query level. So I want to see option 2 > > used all the way up the chain from a basic core component to > > a business > > process schema. Is that in-line with your conclusions? > > </Quote6> > > > > That is 100% in line with my conclusions. > > > > <Quote7> > > If yes, then can I get copies of any premiminary work on this > > - on the > > understanding that it may very well change but at least my project > > deliverables (and associated Australian Standards) will me > > more in line > > with the eventual outcome of your work. I am a paid up member of OASIS > > and can join any team if that is the best way to leverage / contribute > > to your work. > > </Quote7> > > > > As we have not yet embarked on the "next phase" of the Core Components > > Review work, there is actually no preliminary work yet done. The > > archives for the CC-Review TC will have all of the work we did Jan-Aug > > of 2002, but much of that is no longer applicable as it was > > based on the > > previous CCTS spec version. > > > > But most importantly: > > > > On behalf of the Registry TC, we would be *ecstatic* to have you > > participate in this work as part of the Core Components Review > > subcommittee, and the Registry TC as well. Your deep understanding and > > wonderful insight will be very valuable for us. Please > > consider this and > > join through the normal OASIS procedures if you choose to do > > so. We are > > just about to being pushing this effort forward. > > > > I hope this information was helpful to you. > > > > Kind Regards, > > Joe Chiusano > > Booz | Allen | Hamilton > > OASIS/ebXML Registry TC > > Chair, Core Components Review Subcommittee > > </EMail> > > > > Diego Ballvé wrote: > > > > > > 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 > > > > > > > > > > --------------0BC9236B0587863FFE282A3E Content-Type: text/x-vcard; charset=us-ascii; name="Chiusano_Joseph.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Joseph Chiusano Content-Disposition: attachment; filename="Chiusano_Joseph.vcf" 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 --------------0BC9236B0587863FFE282A3E--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]