Reg Rep comments

[nagwa <nagwa.abdelghfour@sun.com>]

Hi All,

Bob and Joe are the only two who send me comments, their comments are
included at the end
of this email with some other comments.

In my opinion ,and also Bob, we should ask to hold this spec until we
receive the Registry Services spec,
I found many technical issues with this spec, which may be resolve when
we read the
Registry Services. But any way here are some of the issues

The summary of the Spec :
Technical Issues:
- The information Model does not clearly explain some of its major
components
 and how they are related to each other ( such as packages and its
components)
- It is clearly assuming that the Object will contain behavior ( page 23
)
-  Some disagreements about the scope of  classification.
- The use of the Association very overloaded
- The choice of some of the components are very odd ( Postal address,
contact ),
 what is special about them and why they are consider components and not
just
attributes like the rest of the metadata
- It seams that the search will be done through a client program, not
through
  a User Interface, Section 12.1.2


General Issues
- Oasis reg rep spec is still in draft within the Oasis reg rep TC, it
is not voted on yet by its committee, but it is mentioned in this
spec in several places
- Using the UML concepts of the interface is confusing for the reader
 who does not know UML, and will think it is an API
- Missing or insufficient description  in many on the sections.
- The mention of inheritance in every sections implied that
 it has to be implemented as an object oriented

--------------------------------------------------------

 The collected comments
-----------------------------

This document is lclearly in a good enough form to go out, but it is
hard to
review in the absence of the registry services specification, and I
suspect
that separating the two will make each harder to use for ebxml consumers
and
implementors.  I would strongly recommend that they go out together for
external review even if that means bending the silly rules; otherwise a
lot
of issues will arise from the info model that the services spec will
presumably answer.   At the very least after the other document gets
published there needs to be an editorial pass to cross reference the two

specs to reduce the self-inflicted pain caused by separating them.

The document's usability would also be improved if the relationships to
the
OASIS registry spec and ISO 11179 were made explicit.  Section 4.1 says
that
the spec leveraged both of these but the credibility of this work would
be
enhanced if that were documented.    For example, Section 11 begins with
the
claim that the ebxml classification scheme is a simplified version of
the
OASIS one, and this needs to be justified  given the criticism from
Boeing
about the limitations of uncontrolled keywords for classification.  I
completely agree with Boeing's point, and the ebxml model has to allow
for
one or more standard vocabularies.

Some of the parts of the registry information model seem a little odd,
especially contact, organization, and postal address, which have
presumably
been thought through more completely by Core Components. I can't imagine

some of this information being very useful in the registry. For example,
if
Sun or Commerce One submit objects to an ebxml registry, it would surely
be
making a company or organizational submission, and individual contact
info
would never be part of this.  I also am amused by the suggestion that
the
default phone number is the "land line" one.

"Name" and "GUID" are contrasted but "user friendly context independent
name" for the former isn't very precise.

Minor nit -- some inconsistency in the use of "schema" as both a
singular
and plural form -- most notable in 5.1 and 5.3.  I think the plural of
schema is schemas (or schemata, if you're Greek or pedantic).

-----------------------------------------------------------------------------------------------------------

The goal of this spec, as it is described on 4.1
     Communicate what information is in the registry and how that
information is organized
- The information in the registry is the meta data for a submitting
object, which can be a single
object or a Package. The Package is an object with Associated objects,
the spec does not
clearly defined this relationship, which is one of the major keys to
describe the information Model.
The only information about the Package what is defined in 6.5, which
says “Logically related
ManagedObjects may be grouped into a Package” there is nothing to
explain how they are related.

- Interface Association 10.1, in the field summery and the Method
Summary contains many confusing
and misleading information,
        - ASSOCIATION TYPE_CLASSIFIED_BY, I don’t think the
classification should be association,
        it is to classified the object, and each object can be
classified using more than one classification scheme,
        using it as association is very confusing
        -Association Type_exteneds, one of many cases I could not
understand this case, and there are no
        explanations what they means
        - Association Type implements, it is defined that the source
object implements the behavior defined
        by the target object  “  are these objects contain behavior???”

- Context Sensitive Classification, 11.2.1, I don’t think the scope of
this version of the regrep, is to
defined this very complex case for the classification.

- It is not clear how this information Model will support the companies’
profiles.

-------------------------------------------------------------------------------------

UML diagram
  Throughout the spec, UML diagrams cause confusion. Because it
  uses "interface", some people may be confused in that it is
  actually the API of RegRep, They are in chapter 7 to 13.
  Also, it may misguide readers to the idea of which they have to
  implement the registry server with object oriented languages.

OASIS
  There are several places that mention "OASIS Registry and
  Repository Model" such as in line 221, there is no official document
of OASIS Registry and Repository
  yet, it is still private document for the Oasis TC.

3.2 Document Version History
  Get rid of all history before submitting to QR

3.5 Related Documents
  a) delete this. Business Domain Model is not submitted to QR

4.2 Caveats and Assumptions
  Delete whole section. The spec shouldn't be "living" and it has
  to be frozen at the publishing time.

5.3 What the Registry Information Model Does
  Line 250 and 251 are unclear. What is the meaning of "metamodel"?

5.4 How the Registry Information Model Works
  Line 254-256 are confusing. Some people may take this as a promotion
  of implementation in an object oriented way.

6 Registry Information Model: Public View

  Figure 1 - It is hard to read for the people who don't know UML.

  Managed Object and Package
    It is not clear how the package is composed of, and the relationship

    between Managed Object and Package

  AuditableEvent
    It is not clear what AuditableEvent means. No description about
    AuditableIdentity

7 Registry Information Model: Detail View
  IntrinsicObject and ExtrinsicObject
    It is not clear what the difference between them is.

8 Registry Audit Trail
  The word "audit" doesn't look fit to the actual purpose. It is hard to

  understand how those "audit-*" is used and why it is needed. Needs to
be
  elaborated.

12.1.2 Ad Hoc Queries Based on Object Metadata And Content
  It looks like Query is performed not only the metadata but also the
  registered content. But that is not true. Searchable items should be
  metadata and the special content such as company profile only.

----------------------------------------------------------------------

Although I have a few concerns, at this point, I really don't have any
problems with releasing this for
general ebXML comment.
It's perhaps not perfect, but I don't see any reason to hold it back.
(Heck, if it _were_ perfect, we
wouldn't need any comment period!)