[Fwd: [ebxml-dev] [Fwd: Mapping of CCTS 1.8 or 1.9 storage model to ebXML RIM]]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

All,

This discussion of Core Components and ebXML Registry took place on
ebXML-dev. Since not everyone is subscribed to ebXML-dev, I wanted to
forward it as it includes the most current thinking regarding our Core
Components work.

The poster is Steve Capell of Australia, and he asked some very specific
questions about our direction in this regard.

Thanks,
Joe

---

• From: "Chiusano Joseph" <chiusano_joseph@bah.com>
• To: ebxml-dev@lists.ebxml.org
• Date: Wed, 02 Apr 2003 22:55:18 -0500

[Forwarding this to ebXML-dev so that it is a public conversation that
others may hopefully benefit from]

---

• From: Joseph Chiusano <Chiusano_Joseph@bah.com>
• To: Steve Capell <steve.capell@redwahoo.com>
• Date: Wed, 02 Apr 2003 22:11:51 -0500

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

Steve Capell wrote:
> 
> Joseph et al,
> 
> Many thanks to all for your constructive input.  It sounds like the work
> is already well under way under Joseph's leadership.  Question - are you
> also looking at binding to the CCBP specification (v0.9 DRAFT) for
> business process as well as core components?
> 
> Also, I have to deliver something before the end of this month so I'd
> appreciate any preliminary work you may have done so that we can at
> least have partial alignment with your final outcome.  Also willing to
> contribute as time permits.
> 
> Regards,
> 
> Steve Capell
> RedWahoo
> Sydney, Australia
> Tel : +61 410 437854
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, 3 April 2003 2:40 AM
> To: CRAWFORD Mark
> Cc: Farrukh Najmi; Steve Capell; Ebxml-Dev@Lists. Ebxml. Org; Mary Kay
> Blantz (E-mail); Alan Stitzer (E-mail); kathryn.r.breininger@boeing.com
> Subject: Re: Mapping of CCTS 1.8 or 1.9 storage model to ebXML RIM
> 
> Mark et al,
> 
> The OASIS/ebXML Registry TC has already been in some great discussions
> with Mary Kay and Alan on this. We will be creating this binding within
> the Registry TC, under the Core Components Review subcommittee.
> 
> Thanks,
> Joe
> 
> "CRAWFORD, Mark" wrote:
> >
> > Farrukh wrote -
> >
> > > Defining a binding from CCTS to ebRIM makes a lot of sense. This has
> 
> > > been discussed within regrep mailing lists in the past. Question is
> > > who defines this binding, who maintains it and whether it is
> > > normative.
> > >
> > > I have proposed that the CCTS-ebRIM binding be a normative binding
> > > defined by CCTS and maintained by CCTS and that the ebXML Registry
> > > TC offer consulting on that effort. To do so would be a decision up
> > > to the CCTS team.
> > >
> > > Until such a decision is made a pragmatic solution may be that
> > > someone who takes the first stab at the binding (e.g. you) write a
> > > brief Technical Note on the binding and submit it to ebXML Registry
> > > TC for review and approval. Tactically, an approved Technical Note
> > > (sometimes referred to as Best Practice) would encourage consistency
> 
> > > even in the absence of a normative spec from CCTS team.
> >
> > Farrukh and Steve,
> >
> > I would welcome the opportunity to discuss this in more detail.  I
> > also believe that Mary Kay (chair of the UN/CEFACT Working Group) and
> > Alan (CCTS Project Lead) would also be open to establishing a project
> > within UN/CEFACT CCWG to accomplish this work.
> >
> > Mark

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

---

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

---

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