Regrep: Exemplary response

[Terry Allen <tallen@sonic.net>]

>From one of the folks doing the NIST implementation, in response
to a suggestion of mine from Saturday, which I copied to this list.

I would like to see more along these lines from the Sun+Documentum
team:  reasoned prose directed to the committee writing the tech
spec for group discussion.

regards, Terry

[headers abridged]
Date: Mon, 13 Mar 2000 17:22:47 -0500
To: regrep@lists.oasis-open.org
From: Len Gallagher <LGallagher@nist.gov>
Subject: Re: eliminate regrep submission stuff?
In-Reply-To: <200003112310.PAA11615@sonic.net>
Mime-Version: 1.0
Sender: owner-regrep@lists.oasis-open.org
Reply-To: regrep@lists.oasis-open.org


Terry and other RegRepers,

I have no problem with simplifying or eliminating the "OASIS Registry and
Repository Zip Format for Submissions" document (rzipformat.htm).  But if
this implies deletion of the <oasis-manifest> DTD and the <cover-letter>
and <submission-purpose> elements, as Terry implies below, then I think the
OASIS specification is losing something very important.

A Registration Authority (RA) needs to have some notion of a "submission
package" so that they can timestamp the receipt of such a package from a
Submitting Organization (SO) and know what to do with the items or
instructions it contains.  A <submission-package> needs to identify the SO
, the <submission-purpose>, and at least one <data-element> so that the RA
can determine what RegRep actions to take.

In the current specification, the <oasis-manifest> DTD and the
<cover-letter> element play the role of a "submission package".  If they
are eliminated, we lose much of this information - especially the
<submission purpose> and the "root" node of a submission.  Without a
<submission purpose> the RA doesn't know if the item is a new submittal, a
new version to co-exist with an existing version, a revision, a
replacement, or a withdrawal.  It seems that the only action an RA could
take without further communication with the SO would be to place all new
items in the registry, even if they duplicate an existing item.  

Maybe the <registry> DTD could play the role of a "submission package", and
could also serve as the "root" node of a submission - but this needs to be
made clear someplace along with the <submission purpose>.  I'm not keen to
put the <submission pupose> in with the <register> element of the
<registry> DTD because it's not an item to be registered.

Other questions that come up with the <registry> DTD are:

1) What happens with <classification-scheme> DTD's? Are they registered
together with <data-element>s, or are they treated special?  Or both?

2) If a single <data-element> is submitted as one item in a
<data-element-dictionary> element having no other meta-information, are
they both registered as distinct items in the Registry? Can I submit a
<data-element> for registration if it is not part of a
<data-element-dictionary> element?

Having a well-specified "submission package" would ameliorate these
concerns. I think we need to have such a root element even if its content
is initially very simple with just new items to be registered. Then later,
as various SO instructions to the RA materialize, e.g. the various
revision, replacement, or withdrawal options, we'd have a place to specify
the content of those instructions.

In conclusion - I'd like to see a DTD for a <submission package> that
replaces and refines the important roles now played by <oasis-manifest>,
<cover-letter>, and possibly <register>.

I also sense that a <submission package> should specify just the semantics
for the content of a message from an SO to an RA.  I think communications
among RA's will have slightly different semantics geared more toward bulk
transmittals that probably deserve distinct message structures, e.g.
associations among registered items may not all be received from the same
SO at the same time so it might be better to transmit associations
separately in RA to RA communications.

Sincerely,
Len Gallagher



At 06:10 PM 3/11/00 , Terry Allen wrote:
>11 March 00
>
>Despite the interest expressed at the recent San Jose meeting
>in having a method of submitting items to a Registration Authority
>that would be the same across registries, further discussion of 
>interfaces and methods for submission indicate to me that early
>implementors would achieve better results if they were given a
>free hand.  
>
>So I am suggesting that we leave any specification of this 
>area to later work, and cut back the OASIS spec by eliminating
>the "OASIS Registry and Repository Zip Format for Submissions"
>document (rzipformat.htm).  There should be no impact on the
>interoperability of registries insofar as nonsubmitting users
>is concerned (once the items are registered, how they were
>submitted doesn't matter), nor on the interoperability of registries in
>communicating queries among each other (which we haven't dealt
>with yet).
>
>Deleting that document would imply elimination of the following
>also:
>	- coverletter.txt
>	- the cover-letter and submission-purpose elements from admin.dtd
>	- oasis-manifest.dtd
>	- the cover-letter-item element from admin.dtd
>	- zipformat.ZIP
>	- much of sect 2.1.2 of the Tech Spec
>	- socontact.txt
>
>The sample file dbra1.txt, which is the RA's composite metadata for the 
>entire Docbook distribution, should be retained and positioned elsewhere,
>I think. 
>
>The conformance language (yet to be written) should probably still refer to
>the roles and responsibilities of the RA outlined in 11179, part 6, sect 6
>(except the unworkable IRDI part), as that section does not really 
>specify workflow except in small chunks.
>
>Whether the RA should designate the SO by URN, a question raised by Una,
>can remain an open issue.
>
>Is anyone opposed to this move?
>
>regards, Terry

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