RE: use case questions

[Terry Allen <tallen@sonic.net>]

Scott wrote:
| To restate the idea I put forward, the registry "instance data" (values) I
| refer to is at the document instance level ...

Thanks, that makes sense.

| Next, the M2 level "instance data" is "metadata" (PurchaseDate,
| ShipToLocation, etc. ) and is generalized by its types (DataElementName,
| Definition, Classification, Association, AssociatedURN, etc.).  Conceivably,

All of those are distinct data elements, related by inheritance (suggesting
the need for some semantics for "inherits-from").

| I could search across all DataElementName values for *Purchase* (wildcard=*)
| and find a boatload of definitions and associated information.  I could

That would be a Bad Idea because you'd be relying on naming conventions.
What you want to is search for data elements that are somehow related to
the "Purchase" taxon in some classification scheme.

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

Ah.  Okay, now I understand what you meant.  The diagram collapses 
retrieval and transformation, which I'm viewing as separate.

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

No problem.
...

| 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

That's Len Gallagher's work (and as he emphasizes, not an official
NIST proposal).

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

It doesn't matter for OASIS right now; it would become relevant if we
moved to X3.285 but at the moment we're focussed on filling in the blanks
to support the initial prototype (XML.org) and the NIST implementation.
We don't have an OASIS OO model of the registry.  EBXML does, so I need
to understand it (as I now do) so we continue along in harmony ...

Thanks, Scott.

regards, Terry