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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-coord message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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
* 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

* 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

* 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.

tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

tel;cell:+61 (0)438352228
fn:tim mcgrath

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC