The definition of "Identifier Strings" in the MMS specification
is incompatible with other LSR specifications.

PROPOSED RESOLUTION:

On page 2-3 of dtc/2001-04-06 change the paragraph that
reads:

---- Old paragraph ----

The kind-field of a component is used to represent information
indicating the release, version or mutation of an entry, and can
be empty. An empty kind-field is synonymous with the 'standard'
or most widely accepted version. It is up to the implementation
to document the syntax and semantics of the version information.

To:

---- New paragraph ----

The kind-field of a component is used to represent information
indicating the release or version of an entry, and can be empty.
An empty kind-field is synonymous with the most recent version.
It is up to the implementation to document the syntax and
semantics of the version information.

And also on page 2-3 of dtc/2001-04-06 change the paragraph that
reads:

---- Old paragraph ----

Except for the assumption that an empty kind-field signifies a
standardized version, the revised submission on Biomolecular Sequence
Analysis [BSA99] and the revised submission on Genomic Maps[GM99] use
the same Identifier type and semantics. In these specifications an
empty kind-field signifies the most recent version. The default was
made to signify the standard version based on the general software
engineering principle that applications (in particular end-user
demonstrations) rely on fixed names to generate predictable
results. The potential harm to system reliability caused by the
substitution of new data is seen to override the potential benefit of
using the modified data. This is reinforced by the fact that the newer
data can be accessed from applications by using a non-empty
kind-field.

To:

---- New paragraph ----

An empty kind-field signifies the most recent version as specified
in the revised submission on Biomolecular Sequence Analysis [BSA99].
However, it is strongly recommended that changes be limited to
corrections of data that are clearly erroneous. In particular,
new refinements of existing experimental data should be given
new identifiers.

Change the two paragraphs defining the Identifier Strings as described below

In section 2.3.2 of the specification describing the EntryFactory
Interface, there is a subtle ambiguity that if interpreted the
wrong way would might require indefinite locking of the underlying
data source. In particular the "get_entry_from_id()" method does
not specify a behavior if the id given was not in the list of
ids returned by the method "get_entry_id_list()" or
"get_entry_modification_dates()".

I propose that this be resolved by:

1) adding the following sentence at the end of the first paragraph
of the subsection labeled "Obtaining an Entry Object".

"This method may successfully return an Entry object even when
the id specified was not included in the list returned by
get_entry_id_list().

2) In the first two sentences of the subsection labeled "Retrieving
Lists of Entries" the word "known" be inserted after the word "all"
So that they read:

"get_entry_id_list() retrieves a list of all known entries.

The get_entry_modification_dates() method retrieves a list of all
known entries along with the date they were last modified.

Make the two changes to the text as described below to remove the ambiguity