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.

see below

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

see below

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

see below

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'

see below

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)"

Change "(W3C)" to "(WS-I)"

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".

see below

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...").

see below

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.

see below

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

see below

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

see below

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

see below

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.

see below

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)

see below

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

see below