RE: use case questions

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

I am very open to changes in the wording, and yes the transformation is
optional.  As far as the metalevels are concerned, I am referring to the OMG
MOF definition as a point of discussion. I originally put out the "What is a
Repository" document to stir up this debate since there is ambiguity in the
marketplace on defining what a repository really is. 

To restate the idea I put forward, the registry "instance data" (values) I
refer to is at the document instance level (CompanyXYX, 19991231, Joe Smith)
it is generalized by its types (CompanyName, SubmissionDate, and ContactName
- respectively).  Therefore that type of generalization is a "model" and
therefore resides at the M1 level.

Next, the M2 level "instance data" is "metadata" (PurchaseDate,
ShipToLocation, etc. ) and is generalized by its types (DataElementName,
Definition, Classification, Association, AssociatedURN, etc.).  Conceivably,
I could search across all DataElementName values for *Purchase* (wildcard=*)
and find a boatload of definitions and associated information.  I could
double click from a list, and retrieve either the detailed view of that item
or download a DTD or UML from the repository (depending on the workflow).

Of course, the M3 level is the heart of the debate and OMG is trying to put
a stake in the ground within its definition based on the MOF.  I believe
that is an implementation consideration, and as we have discussed before,
that it could be as simple as a file system as long as the registry properly
classifies it.  

Again, I am open to revising the component diagram.  I would rather do it
later, since it will be revised many times in the course of the development.
The services that we stated in the Business Requirements document ARE
physical services that would be implemented as a component and would also be
represented in the component diagram.  Having said that, we have a bit more
work to do.  

In review of the OASIS prelimary Rose model for the registry, I believe you
have separated the M1 and M2 information (maybe without knowing that you
did).  The ORGANIZATION class is M1, while the aggregate type REGISTRY_ITEM
is at the M2 level.  However, I believe the SubmittingOrg and the
ResponsibleOrg could be moved to a new class called SUBMISSION; a submission
could be contain MANY REGISTRY_ITEMS.  SUBMISSION is a key concept that
supports the idea of "self-service" over the Web, which I believe is crucial
for successful operation.  The SUBMISSION and the ORGANIZATION are at an M1
level.  

Is the M1 level discussion worthwhile?  Probably not especially if it bogs
us down.

I am willing to add into the ebXML Rose model the OASIS registry class
diagram (at least as a starting point).  I typically don't look at data
until I understand the business process first but I am willing to peek once
in a while. 

Scott

-----Original Message-----
From: Terry Allen
To: ebxml-regrep@lists.oasis-open.org
Sent: 3/7/00 6:20 PM
Subject: use case questions

Scott,

In the use cases, under Component View/Main, there is the note
"Registration
Authority inserts data into repository; a transformation will occur from
an
M2 metalevel to an M3 metalevel".

Could you explain?  what's transformed?  I expect the repository to
store what I put in it without transforming it; if TMWG wants an
automatic
transformation, I would model that as an action performed by an
exterior service before insertion.  But maybe you're talking about 
the metadata for the registered and deposited object.

I have to say I don't understand in their entirety the entries for
<<M3>> Repository 
and <<M1>> Registry as they're currently phrased.  I don't think of a
Registry
as an instance of a modelling technique, nor do I think of a Repository
as a
metametamodel.  Are these also references to services?

regards, Terry