[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Report on the RegRep Information Model v0.52
Lisa and team, The attached URL has the report from the last QR review cycle. Hope it helps. http://lists.ebxml.org/archives/ebxml-coord/200101/msg00013.html -- Regards, FarrukhTitle: Report on the RegRep Information Model v0.52
|
ebxml-coord message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] Subject: Report on the RegRep Information Model v0.52
The Quality Review team have completed their review of the Registry Information Model Specification v0.52 as submitted by the Registry and Repository team on Dec 28th. We recommend that this document in its current form does not go forward for public review. However, what we would like the suggest (via the Executive) is that: a. The Reg Rep team consolidate the Information Model and Registry Services specification into a single document b. The Reg Rep team take on board the Content issues raised below as part of this consolidation process (and any Editorial issues at their own judgement) c. The combined document be submitted for QR on (or before) January 22nd 2001 - that is, still on schedule for the Plenary starting on April 2nd. NB We would ask you to confirm this schedule, our diary allows that... Week commencing - task 22nd Jan - Quality review (round 1) 29th Jan - Executive Review (round 1) NB this may be shorter 5th Feb - Public review (round 1) 19th Feb - editing of comments (round 1) 26th Feb - Quality review (round 2) 5th March - Executive review (round 2) NB this may be shorter 12th March - Public review (round 2) 26th March - editing of comments (round 2) 2nd April - Plenary starts (voting on 6th April) The justificiation for this recommendation is based on three factors: 1. the current specification has deficencies which need to be addressed. Some of these will be resolved by combining the documents. 2. keeping the two specifications separate will "generate more heat than light" i.e. cause more confusion than resolution. for example, it is not possible to complete the ebXML Requirements matrix for this document in isolation. 3. the Registry Services specification is due for submission in the next few weeks and both specifications will be voted on in the April plenary. They are inter-dependant from an implementation viewpoint. To address the detail of point 1, we have identified the following issues that should be addressed before this material goes for public review: Content issues - need to be addressed --------------------- * the document sometimes fails to distinguish between the 'content' and the 'metadata'. (eg. the descriptive boxes in Figure 4 Line 349) * the model breaks into detail with some objects (e.g. Organization-Contact-PostalAddress) yet it remains silent on others (e.g. Language). we suggest that the model should avoid breaking out these objects. * the description of methods for some objects (eg. line 489 "getOrganization()" ) goes beyond the scope of an 'information' model and hence would be better specified with the Registry Services. This could be avoided by combining the two specifications. * in some instances, the document fails to meet its stated goal of "Communicate what information is in the Registry and how that information is organized". For example: a. a 'Package' is both a set of ManagedObjects and a ManagedObject itself. The model does not show this. b. the diagram on Figure 1 appears incomplete. There should be a more direct navigation between ManagedObject and Organization. * the term 'association' is overloaded in that it is used as an interface and to describe the relationship between objects. * some of this material needs alignment with Core Components... a. to ensure the CC 'contexts' are implementible with the 'Classification' model. b. section 9 could be based on, or shared with CC Naming Conventions. c. maybe 'Organization' should be a subset of CC 'Party'? Editorial comments - NB these do not affect the recommendations of QR Team. --------- * UML diagrams - these need a legend to assist those not familair with the technique. For example, some people may read the term 'Interface' to mean some form of API. * OO methodology - whilst it is useful to use these concepts to describe the model, a. the disclaimer (line 258-259) should be more prominent b. as with the use of UML a basic definition of terms (or reference to the ebXML glossry) and concepts would prevent some confusion. * the terminology used should be aligned with the ebXML Glossary. For example, the terms - 'audit' (section 8), 'metamodel' (line 250-251) and the difference between 'class' and 'object' (line 246 and line 270) are unclear. * wherever "Party Profile" and "Party Agreement" are used it should say "Protocol Profile" and Protoocl Agreement". * line 227 - this is not a living document - for the purpose of these discussions it is static. when it is updated another document will be issued. * line 214 - remove editorial comments before submission to QR. In conclusion, we do not wish this recommendation to be taken as a criticism of the excellent work done by the Reg Rep team. the QR Team were greatly impressed by the intelligent content and concise presentation of the document and believe that the issues raised can be addressed and incorporated into a combined specification within the timeframe of the April plenary meeting. To assist in this matter, representatives of the QR team would be willing to brief the Reg Rep team directly via teleconference. We await your consideration on this report. -- regards tim mcgrath TEDIS fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142 begin:vcard n:McGrath;Tim tel;pager:+61(0)299633829 tel;cell:+61 (0)438352228 tel;fax:+61(0)893352142 tel;work:+61(0)893352228 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:tmcgrath@tedis.com.au x-mozilla-cpt:;-23520 fn:tim mcgrath end:vcard [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home] Powered by eList eXpress LLC |