atom feed77 messages in org.oasis-open.lists.regrepRe: [regrep] Impact of ICG Adoption o...
FromSent OnAttachments
52 earlier messages
Chiusano JosephSep 20, 2004 5:20 pm 
Duane NickullSep 20, 2004 5:49 pm 
David RR WebberSep 20, 2004 6:31 pm 
David RR WebberSep 20, 2004 6:33 pm 
David RR WebberSep 20, 2004 6:35 pm 
Duane NickullSep 20, 2004 7:34 pm 
Matthew MacKenzieSep 20, 2004 7:42 pm 
Matthew MacKenzieSep 20, 2004 7:45 pm 
Duane NickullSep 20, 2004 8:52 pm 
Duane NickullSep 20, 2004 9:43 pm 
David RR WebberSep 21, 2004 5:37 am 
David RR WebberSep 21, 2004 5:38 am 
David RR WebberSep 21, 2004 6:40 am 
Farrukh NajmiSep 21, 2004 7:27 am 
Duane NickullSep 21, 2004 7:53 am 
BEDINI Ivan RD-BIZZ-CAESep 22, 2004 9:58 am 
Duane NickullSep 22, 2004 10:14 am 
BEDINI Ivan RD-BIZZ-CAESep 24, 2004 9:24 am 
Duane NickullSep 24, 2004 9:50 am 
BEDINI Ivan RD-BIZZ-CAESep 27, 2004 2:59 am 
Farrukh NajmiSep 27, 2004 4:15 am 
Rex BrooksSep 27, 2004 5:11 am 
Duane NickullSep 27, 2004 8:26 am 
BEDINI Ivan RD-BIZZ-CAESep 27, 2004 11:58 am 
Duane NickullSep 28, 2004 11:57 am 
Subject:Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was:[regrep]UN/CEFACT-ICG adopts freebXML Registry)
From:Duane Nickull (
Date:Sep 28, 2004 11:57:41 am

Yes - the UN *should* develop and publish a set of CC's and ACC's. It will take more time however. I once criticized the CC group for moving too slowly but once I attended a few meetings, realized that their task is way more complex than it seems at first glance. I am confident they will get the job done in time.

In the meantime, others starting implementing the CCTS work (Government of Canada, UK gov used the methodology, others). A good technology cannot be waited for. I think there are benefits to working on it separately too. It can identify potential issues.

If possible, I will help with your groups implementation. When I get back, I'll set up a webex for anyone interested in seeing what has been done with ebXML Registry and CC's and BIE's so far.

Perhaps the Government of Canada could even be persuaded to donate the source code to open source (hint hint).



Duane: I'm interesting to see your presentation, but next week I will be in Brussels...

We agree with you too. The CC doesn't need to know all the BIE's that are based on it.

About the workflow, I agree with you but not at all. Our experience gives us a possibility to see how Edifrance sees CC and BIE. They have to create ABIE for French companies and to do that they need the relative ACC. To create CC is not at all their work and their wishes. CC is a mean to be transversal on business groups, to share a common effort to define data elements and of course to standardize components. UN/CEFACT has to play his role in this work and the TBG 17 could be taking an important part in the harmonisation of this process. After every group, vertical organisation, have to create, validate and manage their Business Context and their relative BIE. I don't think that the UN/CEFACT has to participate in this process.

Best regards (and have a good time in Europe)

-----Message d'origine----- De : Duane Nickull [] Envoyé : lundi 27 septembre 2004 17:30 À : BEDINI Ivan RD-BIZZ-CAE Cc : Objet : Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was: [regrep]UN/CEFACT-ICG adopts freebXML Registry)


Good comments. In general, I think this may be an issue to raise with the Core Components group. I did not encounter the same problem so it was not on my radar.

More comments inline:


For example our feel about Basic UML model of CC and BIE serialisation that you propose can't really be used to store correctly CC and BIE.

[DN] There are actually a few agencies who have used it to do this with no problem. That process is not well documented within the latest spec however. This is a by product of too few people working on it.

IB - Good thing, but how we can re-use the components they are creating?

[DN] We built a complete demo using what the CCTS team used to call an Assembly Document. This is a document that binds the basic or aggregate CC's to a transaction during the design time. We then built a declaration for how to declare a set of 8 contexts. We fed these two items into our assembly utility and it spits out a contextually correct XML schema, using the correct BIE's.

The key is how to allow someone to find the same BIE derived from a BCC or ACC, if they are using the same set of contexts. This requires an infrastructure for storing, searching and associating BIE's and CC with each other. It demands use of a context "key" (*we used the UUID format) for a set of 8 contexts. It also suggests that an ebXML Registry and repository may be the perfect mechanism for storing and classifying them so that others can re-use existing ones, rather than creating new ones.

I would like to suggest a telephone conference call where I can demo this online. I can set up the phone conference if someone else wants to get the service for screen sharing like Webex. I am away in London, UK for the next 4 days however.

The aim is to define CCs as basis to create BIEs (may be messages when the CCTS will be complete about this subject) for real business needs. Already I can't distinguish a BCC from another component with this representation.

[DN] Agreed and a BIE should know the CC that is its' "parent". The other way around is not true - a CC does not need to know all the BIE's that are based on it but having that information handy will likely be helpful for implementors and users.

If you take an ACC instance, it has a lot of properties. These properties could be ASCC or BCC after the BCC are associated with DT ecc... how do you think to take all the information in your serialisation ?

[DN] We have not got to the aggregates yet. When aggregating several CC's and/or BIE's into an aggregate CC or BIE, the properties are carried by way of reference to the base CC's properties. What is not understood at this time is if any of those properties can be further constrained, how we express that in the ACC. It is no problem with the BIE since we used XML schema to express the constraints inline, within the <Representation> element.

Any suggestions you may have are appreciated.

IB - This is the problem that you have when you have BCC alone. In my understanding, the CCTS don't accept BCC or BBIE alone, without the respective ACC. It doesn't have a lot of sense. They have to be attached to an aggregate which has is context (for BIEs) and, consequently, its version.

page 78 of CCTS 2.01 [S16] Stored Basic Core Components shall represent a Basic Core ComponentProperty of a particular Aggregate Core Component. [S18] Stored Association Core Components shall represent an Association CoreComponent Property of a particular Aggregate Core Component.

[DN] in this case, using the Registry information mode is useful to declare that association. Association CC's can be kept in RIM instance data.

A modification to a CC has to be approved by the TBG group and the most important 'exercise' that the validation authority has to do, is to assure the backwards compatibility. So they can't change your components without to be sure that the condition is verified. And for the BIEs the same system has to be adopted. Any official components has to be approved by a specialised validation authority. (see the document of the workflow procedure of UN/CEFACT for that : ures20040312.pdf)

[DN] The methodology is potentially a bit flawed. No authority could ever read all the possible combinations of how someone uses their CC if CCTS became the dominant technology for building business messages. There could simply be way too many.

I think it is more likely that vertical organizations will use and extend the base set for harmonization within their verticals to begin with. There is one set of 353 data elements (we do call them justice core components) available at:

under "data elements".

Talk to you all in a few days.

I suppose that each BCC property that you have in your ACC has to be an implicit link to another 'object' and not the simply name of it.

[DN] That is what I envisioned. Once again, however, the issue is how to express that a property in the BCC is further constrained in the ACC. For example, a BCC has a property that it can contain an attribute with an enumerated list of A to Z. When it is used in conjunction with other BCC's to form a ACC, the range is restricted to C to M. IMO - such restriction makes this a ABIE, not a ACC.

Another point, we don't understand is the mapping of specific Core Components terms model. Why you put CCT, supplementary component restriction, Supplementary Component and associations in this table ?

<Property name="component restriction" value="my restriction" />

The mechanism we used is extensible and will not destroy implementations if it is extended. It therefore preserves forwards/backwards compatibility.

IB - How do you store the CCs in the ebXML Registry , how do you map your serialisation to ebRIM (this is what we'd like to know) ? for example : Properties seem to be Slots, Representation seems to be an ExtrinsicObject where you store all, CCT, SCC, ContentComponet or DT.

[DN] I would like to be present in the ICG process when we start this.

IB - I agree with you, but I think that our work is to map CCTS with ebRIM. Do we really need another intermediate representation ?

for reference, the Canadian GOvernment has some data elements live in a registry repository here:


Best regards Ivan Bedini

-----Message d'origine----- De : Duane Nickull [] Envoyé : mercredi 22 septembre 2004 19:17 À : BEDINI Ivan RD-BIZZ-CAE Cc : Objet : Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was: [regrep]UN/CEFACT-ICG adopts freebXML Registry)


Please take a look at the work of the Registry CC-Review Sub Committee. We have planned to give this work to CEFACT to advance this.

(need OASIS username and password to get in)


Hi to all, We've worked with UN/CEFACT ICG to redact the UN/CEFACT Repository Strategy and at the meeting we have presented our Registry prototype. This prototype allows users to store and retrieve French BIEs in an ebXML RR for EDIFRANCE and it represents a major input for the UN/CEFACT Repository Solution. This project gave us experience on your questions. So we'll try now to share our experience.

First of all we have to concentrate on UN/CEFACT's prototype real needs. Our suggestions are: - Compliance with CCTS is the first fundamental point. We have to define the ebRIM components whose maps with Core Components (ACC, BCC, ASCC, DT, CCT) and all their attributes. For example what will be in ebRIM the respective CCTS Unique Identifier, version, Dictionary Entry Name... and of course their syntax ? Will be the ASCC an ebRIM association, the ACC the ebRIM extrinsicObject or other... ? - The goal of the registry is to manage the submission, modification, validation, versioning, search and retrieve etc... of stored components defined by UN/CEFACT. - Manage Workflow procedures between the UN/CEFACT groups (TBG, ATG & ICG) for Business Specification and Technology Solution transformation publication (ebXMLRR Notification ?)

RepXML prototype gives us a good vision about drawbacks and problems for this purpose.

Best regards

Ivan BEDINI R&D Engineer France Telecom R&D/BIZZ/PMX

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to