RE: Self Service UML Model changes posted

[Terry Allen <tallen@sonic.net>]

Scott wrote:
| Trust itself is a challenging proposition.  I have been involved in some
| debates regarding the "trust" issue.  Some people disagree who can be
| trusted, without defining what the criteria is for trust.  I strongly
| believe that in the ideal world, there can be a level of tranparency of WHO
| the submittor is, and judge them only on the quality of their content.  That
| is why the Quality Assurance Service was introduced in the Business
| Requirements document.  I believe that if you implement in software a check
| against the metamodel for the types of information that you require in a
| submission, this can be achieved.  The definition of this metamodel is our
| dependency from the Business Process project team.  However, that only works
| well if there is a requirement on the format of the submissions, which
| contradicts the "submit anything in any form" business requirement.

I see.  "Submit anything in any form" could be made to apply to related
data for something in one of the formats the registry is set up to
handle.  Then if the submission's "principal registered item" (see
attached) is in one of those formats the software check would pass it.
That might harmonize the two requirements.  (The attached is a message
to the OASIS regrep and XML.org lists re the proposed prototype for
the OASIS registry.)

| I think what you looking for is a "prescreen of registrations" use case
| which is currently missing from the model (thanks).  This could be a
| detailed background check or a simple profile review before they allowed to
| submit their content.  Yes, we must prevent garbage submissions (spam and
| the usual sorts popular on the Net).  I think we should go the route of
| requiring a detailed profile to be set up first, a list of potential
| contributing individuals, and background / intent statement of their use of
| the "system".  

Yes, do this the first time (when they register as an SO) and then
trust them modulo the software check.

| Finally, I don't think we have much choice in the BSR topic.  There are
| recommendations in the Core Components project team on the use of the BSR
| for naming as a requirement.  It is going to hit us like a brick wall sooner
| or later.  I prefer to have a stance on it ahead of time.  I have  prepared
| a two page document that I can post detailing the changes needed to bring
| parts of the specification into the "modern world". :-).   Perhaps we can
| post the document, vote, and table the subject forever.  It will likely come
| up in Brussels since it "close to home" if you know what I mean.

Yeah.  In the Docbook development effort we've been saying for
years that "naming is contentious".  I wasn't aware that Core Components
had approved BSR naming; but I've found that life is much easier now
that I've decided not to have an opinion on naming conventions (aside
from that I know the One True Way ...).

regards, Terry
The Simple Case and the OASIS Regrep Tech Spec

At the recent San Jose meeting of the OASIS Regrep TC
Una (and at least in part Nagwa, but I'll cite Una for
concision) described her view of the relations of the parts 
of a submission.  I wrote in the minutes:

"After some explanation from multiple viewpoints, it became
clear [Terry thinks] that Una wants any given submission to have
the same metadata for all the parts, except for the specification
of relationships among related data, and would even like some
parts of a submission not to have to have metadata other than the
note that they're related to the main piece of the submission.  Terry
realized that the Docbook example in the current spec doesn't show
metadata records for all the related data, and that it should.
Lisa made a distinction between related and associated data.  Do we
really want to have records for all this stuff?  To be discussed in
email."

Robin Cover wrote me a fine message comparing this problem to
problems of descriptive cataloguing in libraries (please post
an excerpt to this list if you like, Robin), and what follows
is pretty much just what Robin wrote, only in different words.

First let me define some terms.

 - "Submission" is a package of information, including if applicable
	the items to be registered, sent by the SO to the RA.

 - "Registered item" is what those items become after they're 
	registered (they are no longer part of a "submission" at that 
	point).

 - "Distribution" is a package of items suitable for downloading
	for examination, such as a set of DTD modules, their
	documentation, and a FAQ.  Docbook has such a distribution.

 - "Set of all related data" ("related data" being a 11179 term)
	is the set of all the items in the registry that are
	related to a registered item.

I believe Una wants to keep the simple case simple, and so wants
to be able to process an entire submission package as one unit
in the registration process.  That's fine.

We need to keep in mind that the set of items in a submission 
package is not necessarily identical to the set of items in a
distribution package.  The set of items in a submission package
may include a distribution package plus all the items separately
(as my Docbook examples show); similarly, a distribution might
contain unregistered items.

The set of all related data may include items from more than one 
submission, such as various versions of the Docbook DTD, which
had been submitted separately.

And, in cases more complex than I think Una is contemplating for the
prototype, the set of all related data may contain items from
submissions by multiple SOs, for example documentation by a 
third party, or commentary on a DTD's structure.  The Tech Spec
must be able to handle that case (which I suspect will be the
common one for NIST's IMS implementation), but I'd like to be
able to let Una keep the simple case simple.

Actually, I don't think anything in the current spec prevents
the simple case from being simple (if we omit the material about
submissions, which I have suggested in a separate message).  There
is something that needs to be added, and on one point we have a 
divergence of views.

The thing that needs to be added is a notion corresponding not
quite to "a principal registered item" (it's pretty hard to
figure out what that would be for, e.g., the Docbook DTD; suggestions
welcome) and not quite to "submission":  it's the key by which
the thing to which related data are related is identified for
purpose of display in the list of related data.  For the
purpose of the dbrelated.txt example I made this the entire
Docbook distribution, but as noted above, that's a simplification,
as the set of related data may not be the same as the distribution.
It's more like a node in a taxonomy (or other classification)
of DTDs.  We can make this something abstract (that is, not
any of the registered items).  It would correspond to the notion
of a literary work:  the Bible is a literary work with
many versions and physical instantiations, none of which is
primary in the way a book's first edition can be.  Robin, is
this what you have in mind?

We might instantiate this notion as the name of an item in
a classification scheme, so that "Docbook DTD" would be such
an item.  Note that this classification scheme would not be
the same as the subject matter classification scheme we know
we need.  That node could then be pointed to, if appropriate,
in the metadata for registered items relating to Docbook. 

Note that in db7.txt I gave the name of the Docbook distribution
as "Docbook DTD," which was an error; that's the name of what
corresponds to a literary work.

The point on which our views (Una's and mine) diverge is this:

I understand Una to want it to be possible to have registered
items that don't have registry entries or metadata, except that
which is inherited from the submission in which it arrived.  
This simplification won't do in an implementation of
11179, and I think it's not right anyway.  In the 11179 model
everything has metadata:  its SO, its representation, its name,
and its name context, for starters.  Representation, name,
and name context cannot be inherited from another registered
item, nor from the submission.  Una mentioned language during
the ACXO meeting; that too cannot be inherited.

(Lisa, you distinguished between related and associated items.
Could you expand on that?)

The 11179 model allows everything registered in the registry to 
be dealt with on the same basis and permits assembly of large-scale 
constructs through the concept of related data.  We don't want
to give that up, and as a group dedicated to Structured Information
Standards, we sure want to implement ISO/IEC 11179 correctly.  It's
going to be the foundation of a lot of other work.

That's not to say that my Docbook examples, which really represent
the metadata as cooked by the RA and probably shouldn't have been
given as examples of how to submit something, are the only way to 
provide the metadata for the items in a submission package.  You
could, in a single document, list all the items in a submission 
package (note that there's no requirement that a submission
consist solely of related items) with their relationships (if
any), representations, names, etc., which is, I think, not far
from the approach Una is taking already, if I understood her
description of her prototype interface.

regards, Terry