atom feed77 messages in org.oasis-open.lists.regrepRe: [regrep] Impact of ICG Adoption o...
FromSent OnAttachments
46 earlier messages
Matthew MacKenzieSep 20, 2004 1:12 pm 
Chiusano JosephSep 20, 2004 1:43 pm 
Matthew MacKenzieSep 20, 2004 1:46 pm 
Duane NickullSep 20, 2004 1:47 pm 
Matthew MacKenzieSep 20, 2004 1:53 pm 
Duane NickullSep 20, 2004 3:19 pm 
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 (dnic@adobe.com)
Date:Sep 24, 2004 9:50:50 am
List:org.oasis-open.lists.regrep

Ivan:

Comments inline:

BEDINI Ivan RD-BIZZ-CAE wrote:

Sorry for later reply.

We already looked the work of the Registry CC-Review Sub Committee and we have bought some good ideas from it, like multiple identifiers for example. But we have not understood your entire document. 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.

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.

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.

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

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

http://ebxml.pwgsc.gc.ca/index.jsp

Cheers

Duane

regards Ivan Bedini

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

Ivan:

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.

http://www.oasis-open.org/apps/org/workgroup/regrep/regrep-cc-review/

(need OASIS username and password to get in)

BEDINI Ivan RD-BIZZ-CAE wrote:

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 http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.