re "What is a Repository?"

[Terry Allen <tallen@sonic.net>]

Notes on "What is a Repository Anyhow" (metalevels.html)
Terry Allen

This makes sense to me; I take note that the goal is "to store 
the model so that a development tool could use the information",
which is more specific that what OASIS is doing, and requires,
as the OASIS spec does not, that the contents of data element
dictionaries be decomposed into a common format - or, in
the words of this document, "mapped to the M3 meta-metamodel 
level."

OASIS isn't requiring this because one of our goals is to enable
DTDs and schemas to be served for parsing of instances, and
it seems like unnecessary work to do the decomposition.  For
ebxml purposes, which I take to be the storage of schemas
for defined e-commerce documents, the decomposition makes sense 
(although for e-commerce in general there will be some documents
that are treated as attachments and the schemas for which needn't
be stored in this repository).

"The question is whether these documents should be parsed into their 
subatomic artifacts and stored into indexed tables in a relational 
database, or do we need to wait for query technologies such as 
XQL to enable high performance search capabilities?"

Not my area of expertise, though we can ask for opinions from
others of the OASIS Regrep TC.  It isn't a new question, and 
I believe the SGML world has learned to live with relational
databases just fine.  I do know at least one person who's not
using a database at all (and it's not me using my file system
and grep ...).  The issue is probably one of what tech is available
for use at our target date (whenever that is).

"The Registry - The main aspect is that a registry implies "to register" 
meaning: what am I registering, who am I, when did I register it (also 
implies what version), how was it created, why did I create it
 (what problem domain) and where is this information located. 
The "who", "when" and "how" are administrative functions. 
The complications occur with the "what" and the "where". If the 
"what" really resides in a repository "somewhere", there must 
be sufficient information about the "what" to point to the "where"
 WITHOUT a complete replication of the repository or multiple 
repositories for that matter (try stating that 100 times fast). Specifically 
some metamodel representations such as UML can generate 
great VOLUMES of rich, semantic information. What is the answer 
to limiting the amount of information in the registry, but ensuring 
enough to find the appropriate information within the repository?"

I am not sure that "why" is required, although I can see the point
of it.  Even "how" isn't obviously required.  For OASIS we made this
the 11179 administrative metadata plus a couple classifications
(see the some of the .ent files at the OASIS site for these).  I suppose
the answer here relates to "what do you want to see in the interface
to the registry?"

X3.285 and metamodels.  I agree it's confusing, and in fact I'm
waiting for the next Open Forum to get caught up on X3.285 again.
Intellectually I'm uncomfortable with the OMG requirement for a M3
level, but not enough to worry me.  Especially as others seem to
like it!  The diagram with M1, M2, and M3 doesn't not make sense
to me; I can't see any need for the M2 if the objects in the M3 have
identifiers.  It's true if the M1 uses, for example, URNs, it needs a 
URN resolution service, but I don't see why that's an M2.

Reading the description below the diagram, I have to say I think
the "locator service" is just part of the registry (the M1).  Why
isn't it?

As for the conclusions:

1. the UML Use Case modeling continue to serve as the basis of the
ebXML Registry and Repository effort without jumping into an 
implementation,
 
2. X3.285 information utilized as much as possible with potential 
convergence of the repository functionality to a pure meta-metamodel 
such as the Meta Object Facility, and 

3. the revised work effort be submitted to SC32 and X3L8 for review 
and incorporation into ISO 11179.

are all fine by me.  I believe that what's in the OASIS spec is a bottom-up
approach to the problem that ebxml is attacking from the top down, and
that as we're in agreement on the core metadata, we'll be able to hook
up in the middle, perhaps with some adjustments on either end.  I'm
still concerned about XMI, but I'm sure I'll learn more in Santa Fe, if
not sooner.











regards, Terry