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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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