Issue 4737: Ambiguity in section 2.3.2 of the specification describing the EntryFactory (mms-ftf) Source: Research Collaboratory Structural Bioinformatics (Dr. Douglas Greer, dsg@sdsc.edu) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Make the two changes to the text as described below to remove the ambiguity Revised Text: 1) Add 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" is to 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." Actions taken: December 5, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Sender: dsg@sdsc.edu Message-ID: <3C0D84F8.82BB9B77@sdsc.edu> Date: Tue, 04 Dec 2001 18:22:49 -0800 From: "Douglas S. Greer" Reply-To: dsg@sdsc.edu Organization: San Diego Supercompter Center X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Macromolecular Structure FTF CC: Juergen Boldt Subject: MMS Issue Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >;$!!P^!e9G_$e9Y\D!! I would like to raise the following issue to the MMS FTF: --------- 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. ---------- Sincerely, -dsg _____________________________________________________________________ Douglas S. Greer, Ph.D. dsg@sdsc.edu San Diego Supercomputer Center University of California, San Diego 9500 Gilman Drive Voice: +1 (858) 534-8357 La Jolla, CA, 92093-0527 Fax: +1 (858) 822-3631 _____________________________________________________________________