Issues for Mailing list of the Life Sciences Identifiers Finalization Task Force

To comment on any of these issues, send email to lsr-identifiers-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 6957: Regarding Life Sciences ID service lifesci 3-5-12, and3-12-02
Issue 7385: compliance point is not clear
Issue 7386: Metadata_document and Timestamp definitions missing
Issue 7387: Some WSDL files use names 'ibm'
Issue 7388: how to use/implement LSIDs on top of existing databases
Issue 7389: misleading wording
Issue 7563: p.13, last sentence (
Issue 7565: double colon
Issue 7569: Metadata ports are ambiguous in WSDL
Issue 7570: Inconsistent capitalization in WSDL
Issue 7571: Spec conformant to WS-I attachments draft
Issue 7572: 'binary64' conformance claim
Issue 7573: Reference incorrectly lists W3C
Issue 7589: incorrect abbreviation DDNS

Issue 6957: Regarding Life Sciences ID service lifesci 3-5-12, and3-12-02 (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

This OMG spec specifies a mapping to Web services in section 8.2.


The second para of 8.2 needs to be clarified to state that only the soap/http binding is conformant to the WS-I Basic Profile 1.0a. The basic profile has placed HTTP get/ mappings outside the scope (i.e., BP 1.0 conformant systems may ignore these bindings).


This Lifesciencs mapping specifies and uses a new WSDL binding extension, FTP binding.


It needs to be clarified that this is an extension to wsdl defined in this OMG spec, and needs to use an OMG lifesciences url (instead of an IBM url) for the namespace of the FTP finding extensions. The actual extension elements need to be defined in a schema which is part of this specification.


The semantics of this new FTP binding do not seem toe be completely specified.
The explanation of the FTP binding (8.2.4.3 Bindings for FTP) should be enhanced.


In particular, it is unclear how the get data with range operation is mapped to FTP, since it states that the binding ignores the input message parts

Resolution: see below
Revised Text: 1) In section 13.2. remove the second paragraph (the one starting with "The WSDL definitions adapted by this..." 2) In section 13.2.2.1 "Bindings for the SOAP over HTTP" insert as the first paragraph the following (note that this text is almost identical with the one remove above; also note that the text here also includes modifications by yet another issue #7571): The WSDL definitions for this binding are designed to be compliant with the WS-I Basic Profile 1.0a [11] and the WS-I Attachments Profile 1.0 Board Approval Draft [12] 3) In section 13.2.2.2 "Bindings for HTTP GET" insert as the first paragraph the following text: The HTTP GET binding is not WS-I compliant and can be ignored by WS-I compliant systems. 4) in section 13.2.2.3 "Bindings for FTP" insert as the first paragraph the following text: The FTP binding is not WS-I compliant and can be ignored by WS-I compliant systems. The FTP binding is not endorsed by the W3C in the Web Service protocols at this time. It is provided for convenience and backwards compatibility with existing Life Science data resources that are available as files using the File Transfer Protocol. The WSDL FTP extension specified here is not intended to serve as a more general purpose mechanism for describing FTP services beyond this specification. For the purposes of this specification, the LSID resolution client utilizing the FTP binding is expected to extract the server name and file path from a WSDL port that references the standard FTP binding described in this specification and access that file using the standard FTP protocol. In the absence of any other out of band information the file transfer will default to an anonymous login with a binary transfer mode. Discussion: (but not requiring a change to the document by the editor): With regard to the FTP binding. The issue asks how the GetDataByRange function is implemented in the FTP binding. The specification, however, already specifies that the GetDataByRange is not implemented in the FTP binding. Consequently the document can remain unchanged on this point. In accompanying files, the letters "IBM" will be changed to "OMG" and the paths will be made consistent – see issue in #7387
Actions taken:
February 5, 2004: received issue
December 3, 2004: closed issue

Issue 7385: compliance point is not clear (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The compliance point is not clear. It should be stated clearly that
implementing only one PSM is enough to become compliant with the spec.  
Also the text there saying "In some places the specification allows, after
giving a proper reasoning, more freedom." should be more specific about 
which places are meant.

Resolution: see below
Revised Text: 1) In chapter 2 ("Conformance"), in the para that starts with "There are compliancy rules:", add as the first bullet the following text: In order to be compliant with this specification an implementation must implement at least one platform specific model. 2) In the same para, remove the bullet: "In some places the specification allows, after giving a proper reasoning, more freedom. If an implementation follows such hints it still remains compliant." 3) In the same chapter, in the para that starts with "There are other, platform-specific, compliancy rules:", add the following bullet: The Web Services based PSM recommends as preferable returning data as SOAP "attachments". The authors of this specification are aware, at the moment of writing, that not all SOAP toolkits (for various programming languages), fully support "attachments". In those cases, the implementations may instead choose to use base64 encoding for the returned values, and still remain compliant with this specification.
Actions taken:
May 28, 2004: received issue
December 3, 2004: closed issue

Issue 7386: Metadata_document and Timestamp definitions missing (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

In PIM, there should be definitions (probably String) for the
Metadata_document and Timestamp.

Resolution: see below
Revised Text: 1a) Change the figure in chapter 7 to a new one (the new one defining the 'Metadata_document as of type String). b) Replace the file LSID-XMI-<version>.xml in the accompanied file with a new one reflecting the new type for Metadata_document. c) Replace the files LSID.[jpg,png] in the accompanied files in order to reflect the same change as described above. 2a) Change the figure in chapter 7 to a new one (the new one defining the Timestamp as of type String). b) Replace the file LSID-XMI-<version>.xml in the accompanied file with a new one reflecting the new type for Timestamp. c) Replace the files LSID.[jpg,png] in the accompanied files in order to reflect the same change as described above. 3) Section 9, page 11, paragraph starting with "The expiration_date specifies..." - add after text "Date and Time Formats" [8]" the following text: “(unless the platform specific model defines otherwise)”
Actions taken:
May 28, 2004: received issue
December 3, 2004: closed issue

Issue 7387: Some WSDL files use names 'ibm' (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some WSDL files use names 'ibm'. This should be resolved to the 'omg', 
or similar.

Resolution: see below
Revised Text: Replace the following files with the new ones where all namespaces are corrected and any other references to 'ibm' are replaced by references to 'omg' (the files are part of the accompanying files): LSIDDataServiceFTPBindings.wsdl SampleLSIDDataServices.wsdl SampleLSIDAuthority.wsdl Note that SammpleLSIDDataServices.wsdl was also changed as described in issue #7569. The provided new file will have *both* issues solved.
Actions taken:
May 28, 2004: received issue
December 3, 2004: closed issue

Issue 7388: how to use/implement LSIDs on top of existing databases (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

 It would be useful if the spec clarifies in text how to use/implement
LSIDs on top of existing databases without changing their internal
schemata.

Resolution: see below
Revised Text: In chapter 9, before the para starts with "The full interface of the LSID Resolution service consists of", add a new paragraph with the following text: "In general, the Life Sciences Identifier can be deployed upon existing databases without the need to modify the databases directly, especially if an appropriately flexible metadata format is chosen. In such architecture, the Life Sciences Identifier authority is serving as a translator between the legacy database retrieval service and the Life Sciences Identifier resolution service. The 'namespace identification' and 'object identification' parts of the Life Sciences Identifier can be used to hold the locator to the data within the existing database. Often the unique database key is used in the ‘object identification’ part of the Life Sciences Identifier although another key, perhaps in an extra column or a combination of columns might be used as the ‘object identification’ part, if that proves more appropriate to the implementer. The Life Sciences Identifier authority can extract the locator from a Life Sciences Identifier presented for resolution and can use the locator to retrieve the data from the existing database. It should be carefully noted that it is essential that once a Life Sciences Identifier has been issued for any particular set of bytes, those bytes should never change. For this reason implementers are urged to take care when mapping databases that apply versioning or simply updating of an existing record by overwriting and should make arrangements to never violate this important rule and use or update the ‘revision identification’ part where appropriate."
Actions taken:
May 28, 2004: received issue
December 3, 2004: closed issue

Discussion:

Issue 7389: misleading wording (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is a misleading wording "both examples..." in the descriprion of
method 'getLSIDPatternFromList'. It should be clarified.

Resolution: see below
Revised Text: 1) On page 15, replace the text "Both examples above could return:" by the following: Both the example invocation of assignLSID and the example invocation of assingLSIDFromList above could return: 2) On page 16, replace the text "Both examples above could return:" by the following: “Both the example invocation ot getLSIDPattern and the example invocation of getLSIDPatternFromList above could return:”
Actions taken:
May 28, 2004: received issue
December 3, 2004: closed issue

Issue 7563: p.13, last sentence ( (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Cambridge Semantics, Inc. (Mr. Sean Martin, sean(at)cambridgesemantics.com)
Nature: Uncategorized Issue
Severity:
Summary:

On p.13, last sentence (Sect 10, LSID resolution discovery service): "Section 8.3 details an example of one such implementation using DDDS/DNS". This should read "Section 13.3"... (not 8.3)

Resolution: see below
Revised Text: On page 13, change "Section 8.3" to "Section 13.3". If the section numbers changes, however, change it to whatever number is now assigned to the section named "Discovering an LSID Resolution Service using DDDS/DNS".
Actions taken:
July 6, 2004: received issue
December 3, 2004: closed issue

Issue 7565: double colon (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 8.1 (page 7) incorrectly states "The LSID declaration consists of the following parts, separated by
double colons". This should read "single colon".

Resolution: see below
Revised Text: In section 8.1 change the text "The LSID declaration consists of the following parts, separated by double colons" to the following: “The LSID declaration consists of the following parts, separated by single colons.”
Actions taken:
July 7, 2004: received issue
December 3, 2004: closed issue

Issue 7569: Metadata ports are ambiguous in WSDL (lsr-identifiers-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Problem : Metadata ports are ambiguous in WSDL:
The spec allows duplicate metadata to be served by different WSDL ports as 
well as multiple ports that are not duplicates. However, the spec does not 
specify a way for the client to determine which ports are duplicates and 
which are true new metadata.


Suggested Solution:
Change the WSDL service name to reference a unique metadata instance, and 
all endpoint bindings contained in that service would be duplicates.  This 
one to one mapping between a service name and metadata would basically 
group duplicate ports into individual services.  By retrieving one port 
from all the services a client is guaranteed to receive all of the 
metadata without retrieving duplicate information.  This standard practice 
would solve the problem and be in the confines of a valid WSLD schema.

Resolution: see below
Revised Text: Include this text as a paragraph in section 13.2.1 before the paragraph beginning "Methods getMetadataand getMetaddataSubset map..." and after the paragraph ending "...by implementing one or more of the interfaces": “When a Life Science Identifier Resolution service provider prepares a WSDL response in which there are multiple bindings for metadata retrieval services the service provider must apply the following policy to these bindings: • The WSDL must define one uniquely named service for each distinct metadata document. • Metadata bindings must be grouped into these services such that all bindings within a service return the same metadata document. • Metadata bindings must not be placed in a service which contains a metadata binding where the two bindings return different metadata documents. • A client can then ensure that it has a complete set of metadata by accessing exactly one metadata port from each named service. • In cases where there is ambiguity or uncertainty as to whether or not metadata retrieval services provide documents that are equivalent, the service provider must assume that they are not, and provide multiple named services as described above.” The updated accompanying WSDL files will include an example of the above. Note that SammpleLSIDDataServices.wsdl was also changed as described in issue #7387. The provided new file will have *both* issues solved.
Actions taken:
July 8, 2004: received issue
December 3, 2004: closed issue

Issue 7570: Inconsistent capitalization in WSDL (lsr-identifiers-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

We have noticed a small issue with the WSDL for the LSID spec. Just a 
small inconsistency.


Issue: Inconsistent capitalization of 'lsid' between the Assigning service 
WSDL and the rest of the WSDL.
Suggested solution: Make following changes to LSIDAssigningPortType.wsdl
                - line 37 - change 'LSIDList' to 'lsidList'
                - line 39 - change 'LSID' to 'lsid'
                - line 43 - change 'LSIDPatternList' to 'lsidPatternList'
                - line 45 - change 'LSIDPattern' to 'lsidPattern'
                - line 77 - change 'LSID' to 'lsid'
                - line 82 - change 'LSIDList' to 'lsidList'
                - line 85 - change 'LSID' to 'lsid'
                - line 94 - change 'LSIDPattern' to 'lsidPattern'
                - line 99 - change 'LSIDPatternList' to 'lsidPatternList'
                - line 102 - change 'LSIDPattern' to 'lsidPattern'
                - line 109 - change 'LSID' to 'lsid'

Resolution: see below
Revised Text: Replace the file LSIDAssigningPortType.wsdl with a new one reflecting the following changes: Make following changes to LSIDAssigningPortType.wsdl - line 37 - change 'LSIDList' to 'lsidList' - line 39 - change 'LSID' to 'lsid' - line 43 - change 'LSIDPatternList' to 'lsidPatternList' - line 45 - change 'LSIDPattern' to 'lsidPattern' - line 77 - change 'LSID' to 'lsid' - line 82 - change 'LSIDList' to 'lsidList' - line 85 - change 'LSID' to 'lsid' - line 94 - change 'LSIDPattern' to 'lsidPattern' - line 99 - change 'LSIDPatternList' to 'lsidPatternList' - line 102 - change 'LSIDPattern' to 'lsidPattern' - line 109 - change 'LSID' to 'lsid'
Actions taken:
July 9, 2004: received issue
December 3, 2004: closed issue

Issue 7571: Spec conformant to WS-I attachments draft (lsr-identifiers-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Issue: The WS-I has released the draft of their attachments profile since 
the LSID spec was finalized. I have verified that the WSDLs are correct 
according to that draft profile. The spec should be updated to mention 
that it is correct with respect to those drafts rather than the 'preview' 
it currently states.
Suggested solution:
        - Section 13.2:  Change "and the previews of upcoming Basic 
Profile 1.1 [12] with support for binary attachments descriptions in 
WSDL."
        to read "and the WS-I Attachments Profile 1.0 Board Approval Draft 
[12]."
        - Update the reference in Section B number 12 to be: 
        WS-I Attachments Profile 1.0 Board Approval Draft: 
http://ws-i.org/Profiles/AttachmentsProfile-1.0-2004-06-11.html

Resolution: see below
Revised Text: Foot note on page 23 *is* still valid. The following changes should be made: - Section 13.2: Change "and the previews of upcoming Basic Profile 1.1 [12] with support for binary attachments descriptions in WSDL." to read "and the WS-I Attachments Profile 1.0 Board Approval Draft [12]." - Update the reference in Section B number 12 to be: WS-I Attachments Profile 1.0 Board Approval Draft: http://ws-i.org/Profiles/AttachmentsProfile-1.0-2004-06-11.html
Actions taken:
July 9, 2004: received issue
December 3, 2004: closed issue

Discussion:

Issue 7572: 'binary64' conformance claim (lsr-identifiers-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Issue: Section 13.2.2.1 mentions that implementors can use "binary64" 
encoding. This should either say "base64" encoding since that is the more 
accepted name for the encoding. Also, it should be explicitly noted that 
doing so will reduce the interoperability of the implementation 
significantly and that the resulting implementation will not be WS-I 
compliant.
Suggested solution:
Either remove this claim now that the attachments WS-I profile is further 
along, or  at least explicitly note that the resulting implementation will 
not be WS-I compliant and might not be interoperable. Also, "binary64" 
should be changed to "base64".

Resolution: see below
Revised Text: The following applies to section 13.2.2.1: Change "binary64" should be changed to "base64". Add the following text to 13.2.2.1 as a new paragraph after the second paragraph ending in “….and still remain compliant with this specification” and before the new heading “Reporting errors”. "Note that implementations that choose to send base64 encoded data within the SOAP messages rather than using attachments will not be WS-I compliant. This is because the WSDLs explicitly say that attachments should be used and the WS-I profiles state that implementations that send messages that do not conform to the relevant WSDL are not WS-I compliant."
Actions taken:
July 9, 2004: received issue
December 3, 2004: closed issue

Issue 7573: Reference incorrectly lists W3C (lsr-identifiers-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This is a small issue but it there is a mistake in the references:


Issue: In Section B, reference 11 incorrectly has "(W3C)" where it should 
say "(WS-I)"
Suggested Solution:
        Change "(W3C)" to "(WS-I)"

Resolution: Change "(W3C)" to "(WS-I)"
Revised Text: Change "(W3C)" to "(WS-I)"
Actions taken:
July 9, 2004: received issue
December 3, 2004: closed issue

Discussion:

Issue 7589: incorrect abbreviation DDNS (lsr-identifiers-ftf)

Click here for this issue's archive.
Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The spec uses on two places incorrect abbreviation DDNS instead of 
DDDS. The suggested resolution is to change it to DDDS (in sections 2 
"Conformance" and 13.3. "Discovering...").

Resolution: see below
Revised Text: Change all occurrences of string "DDNS" in specification document to string "DDDS" in section 13.3 second paragraph and third bullet in second set of bullets in section 2.
Actions taken:
July 14, 2004: received issue
December 3, 2004: closed issue