Re: Call Tomorrow (Len's rethinking)

[Len Gallagher <LGallagher@nist.gov>(by way of Len Gallagher <LGallagher@nist.gov>)]

All,

In a previous email message this morning, I promised to send a new message 
to this list explaining the changes in my thinking that were necessary in 
order to feel more comfortable with the Registry model proposed as a 
compromise by several of us.

My major issue in the past was that nearly every class in the model was a 
subtype of RegistryEntry and thus had to carry along all of the attributes 
of RegistryEntry, even when they made no logical sense. Our proposed 
revision would re-arrange the type hierarchy so that all of these 
attributes on non-RegistryEntry objects are no longer required. I'm very 
pleased with those proposed modifications.

Another issue that concerned me was that "classification scheme" and 
"package" were terms used with dual meaning. One meaning was that these 
terms were metadata used to describe these items and another meaning was 
that they were the repository item itself. The model is now much more clear 
that it supports only the first meaning! I'm OK with that although I'll 
probably still slip occasionally and refer to one of these things 
incorrectly. How about if we agree on the following definitions of these terms:

classification scheme -- a real world term referring to a set of nodes 
arranged in a hierarchy.

ClassificationScheme -- a class in our model that represents only the 
metadata for a classification scheme. It is NOT a representation of the 
classification scheme itself. Thus a ClassificationScheme instance is just 
a RegistryEntry instance, but it is a special RegistryEntry instance that 
may have different relationships with other classes in the model. For 
example, every ClassificationScheme instance will be linked to a hierarchy 
of nodes that represent the real world classification scheme it describes.

package -- a real world term referring to a set of identifiers of other 
instances in the Registry model.

Package -- a class in our model that represents only the metadata for a 
package. It is NOT a representation of the package itself. Thus a Package 
instance is just a RegistryEntry instance, but it is a special 
RegistryEntry instance that may have different relationships with other 
classes in the model. For example, every Package instance will be linked to 
Association instances that determine the membership of the real world 
package it describes.

CAUTION: It the past I've used the lowercase term (e.g. registry entry) to 
represent an instance of the class it identifies (e.g. RegistryEntry). This 
will no longer work (in general) as a convention because "classification 
scheme" is not an instance of ClassificationScheme and "package" is not an 
instance of Package.

Another past issue of mine was that our model would be more meaningful if 
we included a RepositoryItem class. Each instance of this class would 
represent a "repository item" that was referenced by a RegistryEntry 
instance. I always supported the notion that this class was for 
definitional purposes only and was not directly accessible by Registry 
Services.  Because of this restriction, others argued that it would be 
counter-productive to include this class in our model. I'm now OK with not 
having this class in the model -- there should be no effect on Registry 
Services. In the past I argued that this class was necessary to support the 
notions of ClassificationScheme and Package (using the 2nd meaning above). 
However, with the restricted meaning for those terms proposed above, I no 
longer make this argument.

The new proposed model is more general than the existing model because:

i) it allows Classification instances linked to any RegistryObject rather 
than just to RegistryEntry instances,

ii) it allows Association instances whose "sourceObject" is an arbitrary 
RegistryObject instance rather than just a RegistryEntry instance,

iii) it allows Association instances whose "targetObject" is an arbitrary 
RegistryObject instance rather than just a RegistryEntry instance,

iv) it allows Slot instances on any RegistryObject instance instead of just 
on RegistryEntry instances.

The proposed generalization of Slot makes sense to me because we can think 
of it simply as the ability to define a new "attribute" for any class in 
the model. I fully support the generalization of Slot.

I'm less comfortable with the generalization of Classification and 
Association, although I agree that there are good examples of where this 
generalization could be useful. For example, a user could now classify an 
Organization even though an Organization instance is no longer a 
RegistryEntry instance. Or a user could classify an Association instance in 
multiple ways instead of just by "associationType" as in the current 
specification.

My potential concern with this generalization of Classification and 
Association is that it may have a significant impact on how one chooses to 
implement the model. And it could have a significant impact on how 
FilterQuery is specified in the Registry Services document.

For example, the FilterQuery definition in RS makes the assumption that the 
"sourceObject" and "targetObject" of an Association instance will have all 
of the attributes of a RegistryEntry instance.  With the generalization of 
Association, we may no longer be able to make this assumption. The 
sourceObject and targetObject identifiers could point to an object of any 
type in the model.

In my mind, an important issue to be resolved is how much of the potential 
generalization of Classification and Association should be required of a 
conforming implementation? I'd favor a conformance statement that would 
allow an implementation to restrict Classification instances only to 
RegistryEntry or Organization instances as the source, and restrict 
Association instances so that sourceObject and targetObject are 
RegistryEntry instances. Otherwise, the FilterQuery section of Registry 
Services would become much more complex. For example, in RS Section 8.2.2, 
RegistryEntryQuery, the SourceAssociationBranch and TargetAssociationBranch 
would have to be modified to allow the "sourceObject" or the "targetObject" 
to reference an instance from an arbitrary class in the model. It would 
have to provide a way for the user to filter the "Source" and "Target" 
objects by "objectType" and provide options to link to classes of all of 
the possible target types. Admittedly, this provides additional 
functionality, but possibly at the price of too much additional complexity.

-- Len



At 03:37 PM 8/8/01, you wrote:
>Hello All,
>
>As many of you know, throughout the ebXML effort Len Gallagher from NIST 
>had raised serious concerns regarding the ebXML information model and 
>services.  Most of these issues were raised prior to our ebXML meeting in 
>Vancouver.  At that meeting, the committee decided to defer resolution on 
>many of these issues until after Phase I.  So here we are in Phase II.
>
>As those who attended the Vancouver meeting know, Farrukh Najmi (and 
>others) had serious concerns regarding many of Len's issues.    It became 
>apparent to me that some benefit may be derived if I put Len and 
>Farrukh  in a room for a day or so to discuss Len's issues.   So we did 
>just that.
>
>Last week Len, Farrukh, Nikola Stojanovic, and I met for a day and a half 
>to discuss Len's recurring issues.  The meeting was extremely productive 
>in that many issues were resolved to all parties' satisfaction (sort 
>of).   The attached file represents two proposals for changing the 
>information model and inheritance diagrams for the RIM.  (We additionally 
>started a list of bugs that were identified during the discussion.  I'll 
>provide that in a separate message.)
>
>Please recognize that the attached documents do not represent consensus of 
>the OASIS/ebXML Registry TC.  Currently the attached documents are based 
>on the opinions of 3 TC members.  (My role was more of a facilitator than 
>a TC member.)  We will discuss these proposals during the conference call 
>tomorrow.  These proposals will be accepted only if we achieve positive 
>consensus within the TC.
>
>I have a number of other items for the agenda; I'll try and send you email 
>regarding them before the meeting.
>
>Call-in information:  NOTE: THIS NUMBER IS DIFFERENT THAN THE LAST CALL.
>
>CALL DATE:         AUG-09-2001  (Thursday)
> > CALL TIME:         04:00 PM EASTERN TIME
> > DURATION:              2 hr
> > USA Toll Free Number: 888-566-5920
> > USA Toll Number: +1-630-395-0252
> >  PASSCODE: 13852
> >  LEADER:            Ms Lisa Carnahan
>
>--lisa

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************