Issue 7569: Metadata ports are ambiguous in WSDL (lsr-identifiers-ftf) Source: (, ) 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 Discussion: End of Annotations:===== c: lsr-identifiers-ftf@omg.org, juergen@omg.org, Sean Martin Subject: Life Science Identifier Issue (lsr-identifiers-ftf) : Ambiguous Metadata Ports in WSDL X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Dan Smith Date: Thu, 8 Jul 2004 17:22:16 -0400 X-MIMETrack: Serialize by Router on D01ML251/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/08/2004 17:22:18, Serialize complete at 07/08/2004 17:22:18 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. Cheers! Dan Smith -------------------- IBM Advanced Internet Technologies Cambridge, MA To: Martin Senger Cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Wed, 14 Jul 2004 16:32:45 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/14/2004 16:32:48, Serialize complete at 07/14/2004 16:32:48 ----------------------------------------------------------------- Issue 7569: Metadata ports are ambiguous in WSDL ----------------------------------------------------------------- >Frankly, I do not understand this issue. >Are you saying that several data retrieval services can return (for >the same LSID, of course) the same metadata with different value? Such >as using the same predicate (if talking about RDF-based metadata) but >with different object? >I need to understand first the issue before being able to comment the >suggeste resolution. Sorry for that. What we are suggesting is that the exact same metdata file (in whatever format) may be available using multiple protocols (e.g. SOAP, HTTP and FTP). At the same time different metafiles (containing different metadata) may be available for the same LSID from different sources on the network. Ideally the client will want to gather up only one copy of each of the different metadata files for any LSID in order to accumulate all the metadata possible. However to do this efficiently it will want to achieve this without accessing every possible protocol under which the file is available and thus retrieving duplicates of the same metadata file). The convention suggested makes this possible. The WSDL service name references a unique metadata instance, and all metadata endpoint bindings contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. By retrieving one metadata port from each of the services a client is guaranteed to receive all of the metadata without retrieving duplicate metadata. Kindest regards, Sean Date: Wed, 14 Jul 2004 21:48:30 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) Thank you for trying... I still cannot grab the consequences. Perhaps by explaining the individual pieces I may understand (see my comments below). I am really sorry. Generally speaking, I cannot imagine how to avoid to get duplicated metadata - if there is more independent data retrieval services. They simply do not know about each other - so it's hard for me to figure out how a change in WSDL can help me here. > What we are suggesting is that the exact same metdata file (in whatever > format) may be available using multiple protocols (e.g. SOAP, HTTP and > FTP). > What do you mean by "metadata file"? Is it the same as "Metadata_document", the real metadata returned by getMetadata() call? > At the same time different metafiles (containing different metadata) > may be available for the same LSID from different sources on the network. > Ideally the client will want to gather up only one copy of each of the > different metadata files for any LSID in order to accumulate all the > metadata possible. > This would be ideal - but, as I said above, I cannot imagine how to do it when the client calls several independent services (metadata providers). > However to do this efficiently it will want to achieve > this without accessing every possible protocol under which the file is > available and thus retrieving duplicates of the same metadata file). > Do you perhaps mean by this that the same metadata provider may provide the same metadata using more than one protocol? > The WSDL service name references a unique metadata instance, and > all metadata endpoint bindings contained in that service would be > duplicates. > Can you explain me what you mean by "all metadata endpoint bindings contained in that service"? Martin, desperately trying - but still lost :-( -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: Martin Senger Cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Wed, 14 Jul 2004 17:17:19 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/14/2004 17:17:21, Serialize complete at 07/14/2004 17:17:21 hi Martin, No problem.. I dont think I am explaining it very well yet. Lets try another round :-) >What do you mean by "metadata file"? Is it the same as >"Metadata_document", the real metadata returned by getMetadata() call? By metadata file, yes I do mean metadata document (in what ever format that is in). The authority which generates the WSDL for any particular LSID knows a couple of things. It knows all the places and protocols where the data named may be retrieved from and it creates the appropritate getData methods in the WSDL for those. The client side may access any one of those methods and know that it has an exact copy of the data named by the LSID. The authority also knows all the places and protocols where metadata documents can be retrieved from and has a good idea of whether or not these places of retrieval will produce identical metadata documents or not. So sometimes there may be metadata documents for a single LSID that are different (contain different metadata). Supposing we have an LSID with data and two distinct metadata documents with information about that data. All are available using FTP, HTTP, and SOAP protocols from one server additionally one of the documents is also available on another web server via HTTP that the authority knows about. The client wants to retrieve only one copy of both of the metadata documents so as to have all the metadata known about that LSID by the authority. In our example the client is faced with possible 7 getMetaData methods (2 metadata documents x 3 protocols + 1 metadata document x 1 protocol). Without the suggested convention, it will have to access all 7 protocols, retrieving one metadata document 3 times and the other 4. Not too effiecient, plus the client may not be capable of using all the protocols. The suggestion groups the getMetaData methods in the WSDL so that the WSDL service name references a unique metadata instance (or metadata document). The service includes the method for each protocol by which that metadata document may be retrieved. The client knows that if it manages to successfully access a single metadata document from each service listed in the WSDL (using which ever protocol it chooses from those listed as available), it will now have all the metadata documents available to it. >Can you explain me what you mean by "all metadata endpoint bindings >contained in that service"? A metadata endpoint binding (aka port or even method) represents a soap address location (a url and the protocol for calling it [soap, ftp, http]). These bindings/ports can be grouped into services. The suggestion is that all bindings that retrieve the same metadata document should if possible be grouped into the the same service in the WSDL. Kindest regards, Sean Martin Senger 07/14/2004 04:48 PM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org, Michael Niemi/Boca Raton/IBM@IBMUS Subject Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) Thank you for trying... I still cannot grab the consequences. Perhaps by explaining the individual pieces I may understand (see my comments below). I am really sorry. Generally speaking, I cannot imagine how to avoid to get duplicated metadata - if there is more independent data retrieval services. They simply do not know about each other - so it's hard for me to figure out how a change in WSDL can help me here. > What we are suggesting is that the exact same metdata file (in whatever > format) may be available using multiple protocols (e.g. SOAP, HTTP and > FTP). > What do you mean by "metadata file"? Is it the same as "Metadata_document", the real metadata returned by getMetadata() call? > At the same time different metafiles (containing different metadata) > may be available for the same LSID from different sources on the network. > Ideally the client will want to gather up only one copy of each of the > different metadata files for any LSID in order to accumulate all the > metadata possible. > This would be ideal - but, as I said above, I cannot imagine how to do it when the client calls several independent services (metadata providers). > However to do this efficiently it will want to achieve > this without accessing every possible protocol under which the file is > available and thus retrieving duplicates of the same metadata file). > Do you perhaps mean by this that the same metadata provider may provide the same metadata using more than one protocol? > The WSDL service name references a unique metadata instance, and > all metadata endpoint bindings contained in that service would be > duplicates. > Can you explain me what you mean by "all metadata endpoint bindings contained in that service"? Martin, desperately trying - but still lost :-( -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Wed, 14 Jul 2004 22:45:32 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) Thanks for the patience. > The authority which generates the WSDL for any particular LSID knows a > couple of things. It knows all the places and protocols where the data > named may be retrieved from and it creates the appropritate getData > methods in the WSDL for those. The client side may access any one of those > methods and know that it has an exact copy of the data named by the LSID. > Yes, for getData() it is clear. > The authority also knows all the places and protocols where metadata > documents can be retrieved from > Yes, that's clear also. > and has a good idea of whether or not these places of retrieval will > produce identical metadata documents or not > This is unclear. Why should the authority have any idea of metadata provided by individual data retrieval services? For example, I am in the process of writting a special BioMoby service that registers all locations (and protocols) for various metadata repositories (for a given LSID). This service will be able to provide WSDLs for all registered services, but it will not have any idea if the metadata provided by these services will be identical or not. > Supposing we have an LSID with data and two distinct metadata documents > with information about that data. All are available using FTP, HTTP, and > SOAP protocols from one server additionally one of the documents is also > available on another web server via HTTP that the authority knows about. > I guess that by "one server" and by "another web server" you mean data retrieval services (I prefer to use terms used in the LSID spec). > The client wants to retrieve only one copy of both of the metadata > documents so as to have all the metadata known about that LSID by the > authority. In our example the client is faced with possible 7 getMetaData > methods (2 metadata documents x 3 protocols + 1 metadata document x 1 > protocol). Without the suggested convention, it will have to access all 7 > protocols, retrieving one metadata document 3 times and the other 4. Not > too effiecient, plus the client may not be capable of using all the > protocols. > I agree that it would be nice to restrict sending the same metadata *from the same data retrieval service* when the service uses more than one protocol. But I do not think that you can achieve the same from multiple services. > The suggestion groups the getMetaData methods in the WSDL so that the WSDL > service name references a unique metadata instance (or metadata document). > The service includes the method for each protocol by which that metadata > document may be retrieved. The client knows that if it manages to > successfully access a single metadata document from each service listed in > the WSDL (using which ever protocol it chooses from those listed as > available), it will now have all the metadata documents available to it. > Perhaps now it will help to show the new (suggested) version of the WSDL with the behaviour described above. Martin PS. If this discussion seems to need more time to explain, please feel free to ask for the vote for other issues meantime... M. -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: Martin Senger Cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Wed, 14 Jul 2004 18:02:38 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/14/2004 18:02:41, Serialize complete at 07/14/2004 18:02:41 Hi Martin, >This is unclear. Why should the authority have any idea of metadata >provided by individual data retrieval services? For example, I am in the >process of writting a special BioMoby service that registers all locations >(and protocols) for various metadata repositories (for a given LSID). This >service will be able to provide WSDLs for all registered services, but it >will not have any idea if the metadata provided by these services will be >identical or not. In our experience LSID'ifying public data sources this has never been a problem (an authority for an LSID is after all the authority - we are not talking about third parties who have no control over the data, but the authority that actually names & provides the data and who should have some idea about what they are pointing at in the WSDL used to resolve information for that LSID). In the situation you describe, where you do not know if the metadata document are duplicated or not, it soulds like you should probably provide a service for each repository and let the client sort out duplicate/conflicting metadata documents and content. This would still be valid with the scheme we propose. Perhaps we should include some text which states this in the specification? "When an authority service does not have explicity knowledge of the fact that two metadata endpoints return duplicate metadata, it must treat each as a unique metadata endpoint and places each in a different service." ? Any way it sounds like a pretty interesting project, please let me know when it works! >I guess that by "one server" and by "another web server" you mean data >retrieval services (I prefer to use terms used in the LSID spec). You are correct. >Perhaps now it will help to show the new (suggested) version of the >WSDL with the behaviour described above. Good point. We need to do that. Kindest regards, Sean Martin Senger 07/14/2004 05:45 PM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org, Michael Niemi/Boca Raton/IBM@IBMUS Subject Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) Thanks for the patience. > The authority which generates the WSDL for any particular LSID knows a > couple of things. It knows all the places and protocols where the data > named may be retrieved from and it creates the appropritate getData > methods in the WSDL for those. The client side may access any one of those > methods and know that it has an exact copy of the data named by the LSID. > Yes, for getData() it is clear. > The authority also knows all the places and protocols where metadata > documents can be retrieved from > Yes, that's clear also. > and has a good idea of whether or not these places of retrieval will > produce identical metadata documents or not > This is unclear. Why should the authority have any idea of metadata provided by individual data retrieval services? For example, I am in the process of writting a special BioMoby service that registers all locations (and protocols) for various metadata repositories (for a given LSID). This service will be able to provide WSDLs for all registered services, but it will not have any idea if the metadata provided by these services will be identical or not. > Supposing we have an LSID with data and two distinct metadata documents > with information about that data. All are available using FTP, HTTP, and > SOAP protocols from one server additionally one of the documents is also > available on another web server via HTTP that the authority knows about. > I guess that by "one server" and by "another web server" you mean data retrieval services (I prefer to use terms used in the LSID spec). > The client wants to retrieve only one copy of both of the metadata > documents so as to have all the metadata known about that LSID by the > authority. In our example the client is faced with possible 7 getMetaData > methods (2 metadata documents x 3 protocols + 1 metadata document x 1 > protocol). Without the suggested convention, it will have to access all 7 > protocols, retrieving one metadata document 3 times and the other 4. Not > too effiecient, plus the client may not be capable of using all the > protocols. > I agree that it would be nice to restrict sending the same metadata *from the same data retrieval service* when the service uses more than one protocol. But I do not think that you can achieve the same from multiple services. > The suggestion groups the getMetaData methods in the WSDL so that the WSDL > service name references a unique metadata instance (or metadata document). > The service includes the method for each protocol by which that metadata > document may be retrieved. The client knows that if it manages to > successfully access a single metadata document from each service listed in > the WSDL (using which ever protocol it chooses from those listed as > available), it will now have all the metadata documents available to it. > Perhaps now it will help to show the new (suggested) version of the WSDL with the behaviour described above. Martin PS. If this discussion seems to need more time to explain, please feel free to ask for the vote for other issues meantime... M. -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Wed, 14 Jul 2004 23:13:59 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi Subject: Re: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) > In the situation you describe, where you do not know if the metadata > document are duplicated or not, it soulds like you should probably > provide a service for each repository and let the client sort out > duplicate/conflicting metadata documents and content. > Yes. > This would still be valid with the scheme we propose. > Okay, that makes me happier :-) > Perhaps we should include some text which states this in the > specification? "When an authority service does not have explicity > knowledge of the fact that two metadata endpoints return duplicate > metadata, it must treat each as a unique metadata endpoint and places > each in a different service." ? > Yes, something like that. Even though I would probably prefer to have it said other way round: "When an authority does have explicit knowledge..." > Any way it sounds like a pretty interesting project, please let me know > when it works! > Yes, I will do it. > >Perhaps now it will help to show the new (suggested) version of the > >WSDL with the behaviour described above. > Good point. We need to do that. > Okay, let's wait now for it. Thanks again for your explanations. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD Issue 7569: Metadata ports are ambiguous in WSDL Summary: 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 Resolution: Include this text: The WSDL service name references a unique metadata instance, and all metadata endpoint bindings contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. By retrieving one metadata port from each of the services a client is guaranteed to receive all of the metadata without retrieving duplicate metadata. :wq X-Server-Uuid: 48764CE8-FD0B-4606-A1C3-503FAD0548C7 From: "Miller, Michael (Rosetta)" To: "'Sean Martin'" , lsr-identifiers-ftf@omg.org cc: "Martin Senger" , "Michael Niemi" Subject: RE: lsr-identifiers-ftf - proposals for issue resolution II ( plea se discuss!) Date: Thu, 15 Jul 2004 12:52:11 -0700 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6CE83FDE1FK57279-01-01 Hi Sean, Thanks for putting this together with Martin. For 7385: As far as Timestamp goes, string is fine but it should be in ISO-standard format. For 7388: I would add wording to the effect "An alternative key set of columns should be used to define the object portion of the identifier if one is defined on the table, otherwise the unique database key ...." An alternative key is still unique and tends to be more robust than the database key for an identifier. For 7569: numerous misspellings in the suggested replacement text. For 7572: Resolution only addresses first half of the issue--does it make it not compliant to WS-1, if so that should also be stated? cheers, Michael Michael Miller Senior Application Developer Rosetta Biosoftware michael_miller@rosettabio.com www.rosettabio.com -----Original Message----- From: Sean Martin [mailto:sjmm@us.ibm.com] Sent: Thursday, July 15, 2004 11:47 AM To: lsr-identifiers-ftf@omg.org Cc: Martin Senger; Michael Niemi Subject: lsr-identifiers-ftf - proposals for issue resolution II (please discuss!) Summary of issues from lsr-identifiers-ftf copied from http://www.omg.org/issues/lsr-identifiers-ftf.open.html and proposed resolution for each. It has been updated with Martin's comments and instructions for the editor. Some of the edited files are also included as attachments. Please respond with comments to the list. If everyone is happy with this we can proceed to the vote. Kindest regards, Sean ------------------------------------------------------------------------------ Issue 6957: Regarding Life Sciences ID service lifesci 3-5-12, and3-12-02 (lsr-identifiers-ftf) 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 Suggested Resolution: 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 compatability 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 band information, that file transfer will default to an anonymous login with a binary transfer mode. As for 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. - So leave document as is. The letters "IBM" should be changed to "OMG" and the paths should be made consistant. Updated files will be provided reflecting this change. ------------------------------------------------------------------------------ Issue 7385: compliance point is not clear (lsr-identifiers-ftf) 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. Suggested Resolution: 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. ------------------------------------------------------------------------------ Issue 7386: Metadata_document and Timestamp definitions missing (lsr-identifiers-ftf) Summary: In PIM, there should be definitions (probably String) for the Metadata_document and Timestamp. Suggested Resolution: Unresolved!! We are not sure exactly how these are supposed to be defined. But we know the purpose of leaving the Metadata_document somewhat loose is that the specification leaves Metadata extensible. So perhaps, if anything, it should be bytes rather than more than a String as the issue suggests. Timestamp is probably fine as a String. Comments please from more knowlegable folk! 1 a) 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-.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. 2) a) 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-.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. ------------------------------------------------------------------------------ Issue 7387: Some WSDL files use names 'ibm' (lsr-identifiers-ftf) Summary: Some WSDL files use names 'ibm'. This should be resolved to the 'omg', or similar. Suggested Resolution: Replace the following files with the new ones where all references to ibm are replaced by references to omg (the files are part of the accompanied files): LSIDDataServiceFTPBindings.wsdl SampleLSIDDataServices.wsdl ------------------------------------------------------------------------------ Issue 7388: how to use/implement LSIDs on top of existing databases (lsr-identifiers-ftf) 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. Suggested Resolution: 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 approriately flexible metadata format is chosen. In such an architecture, the Life Sciences Identifier authority is serving as a translator between the legacy database retrieval protocol and the Life Sciences Identifier resolution protocol. The 'namespace' and 'object' sections 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 Identifier portion of the Life Sciences Identifer.The Life Sciences Identifier authority can then extract the locator from a Life Sciences Identifier and the authority can use the locator to retrieve the data from the existing database. There are already numerous examples of such mappings widely available. It should be noted however 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 implementors 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." ------------------------------------------------------------------------------ Issue 7389: misleading wording (lsr-identifiers-ftf) Summary: There is a misleading wording "both examples..." in the descriprion of method 'getLSIDPatternFromList'. It should be clarified. Suggested Resolution: 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: ------------------------------------------------------------------------------ Issue 7563: p.13, last sentence 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"... (not8.3) Suggested Resolution: 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". ------------------------------------------------------------------------------ Issue 7565: Error in Life Science Identifier specification Summary: Section 8.1 (page 7) incorrectly states "The LSID declaration consists of the following parts, separated by double colons". Suggested Resolution: 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. ------------------------------------------------------------------------------ Issue 7569: Metadata ports are ambiguous in WSDL Summary: 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 Resolution: Include this text as a paragraph in section 13.2.1 before the the paragraph beginning "Methods getMetadataand getMetaddataSubset map..." and after the paragraph ending "...by imppementing one or more of the interfaces": Where possible the WSDL service name should reference a unique metadata instance, and all metadata endpoint bindings contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. By retrieving one metadata port from each of the services a client is guaranteed to receive all of the metadata without retrieving duplicate metadata. In the case where the implementors are uncertain as to the uniqueness of the metadata instance, they should attempt tp provide a serparate service name for each metadata endpoint binding. ------------------------------------------------------------------------------ Issue 7570: Inconsistent capitalization in WSDL Summary: Inconsistent capitalization of 'lsid' between the Assigning service WSDL and the rest of the WSDL. Suggested Resolution: 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' ------------------------------------------------------------------------------ Issue 7571: Spec conformant to WS-I attachments draft Summary: 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 Resolution: 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 ------------------------------------------------------------------------------ Issue 7572: 'binary64' conformance claim Summary: 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 Resolution: Add the following tex to 13.2.2.1: Change "binary64" should be changed to "base64". ------------------------------------------------------------------------------ Issue 7573: Reference incorrectly lists W3C Summary: In Section B, reference 11 incorrectly has "(W3C)" where it should say "(WS-I)" Suggested Resolution: Change "(W3C)" to "(WS-I)" ------------------------------------------------------------------------------ Issue 7589: Incorrect abbreviation of DDDS Summary: The Life Science Identifier spec uses in two places the incorrect abbreviation DDNS instead of DDDS. The suggested resolution is to change it to DDDS (in sections 2 "Conformance" and 13.3. "Discovering...") Suggested Resolution: Change all occurances 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. -------------------------------------------------------------------------------- Attachments follow ----------- For issue 7387: Here are the files with the ibm namespace changes to the ibm namespace to: http://www.omg.org/LSID/2003/WSDL/FTP Issue 7570: Here is the file with the changes made: To: Martin Senger Cc: lsr-identifiers-ftf@omg.org, Michael Niemi , Michael_Miller@rosettabio.com Subject: #issue 7569 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 08:26:33 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/20/2004 08:26:35, Serialize complete at 07/20/2004 08:26:35 SJM>> Also attached for your perusal, copies of the latest WSDL files. The first SJM>> was modified to illustrate the convention of placing duplicate metadata SJM>> port in the same service. SJM>> MS>Please correct me here: you are saying that only the sample wsdl is MS>going to be changed (if we agree on this issue), but not the WSDL MS>specification itself? The sample WSDL files would be changed (you have the changed files from my last note) and the following would be added as the resolution: Suggested Resolution: 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": .Where possible the WSDL service name should reference a unique metadata instance, and all metadata endpoint bindings contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. By retrieving one metadata port from each of the services a client is guaranteed to receive all of the metadata without retrieving duplicate metadata. In the case where the implementers are uncertain as to the uniqueness of the metadata instance, they should attempt to provide a separate service name for each metadata endpoint binding.. The updated accompanying WSDL files will include an example of the above. Date: Tue, 20 Jul 2004 14:36:43 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org Subject: Re: #issue 7569 X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) > The sample WSDL files would be changed (you have the changed files from my > last note) > I am confortable to have this newq Sample file. But the text should be clearer (even though now I think I understand the point): > Where possible the WSDL service name should... > I would start "from the other side of the problem. Something like this: --- begin --- An LSID Resolution service provider - if it provides WSDLs for data retrieval services, any of them with several bindings for the same metadata - should make clear that each of these bindings will deliver the same metadata, so the client can choose only one binding and still be sure that it gets all metadata available from this particular data retrieval service. This can be achieved by... (and here you can continue similarly what you have in your suggeste resolution). In the case where the Resolution service provider is uncertain as to the uniqueness of the metadata provided by individual bindings, he should attempt to provide a separate service names for each metadata endpoint binding. --- end --- Such text seems to be more understandable. But of course, I am not an English-native speaker so I ma be completely wrong. Also I am personally uncertain that the second paragraph in the text above is really necessary. I tent to suggest to remove it and not to mention what to do in such case (we may end up in the conformace issue again). Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: Martin Senger Cc: lsr-identifiers-ftf@omg.org Subject: #issue 7569 text updated X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 11:10:09 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/20/2004 11:10:11, Serialize complete at 07/20/2004 11:10:11 Hi Martin, I have updated the text for the suggested resolution to include your comments. How does this look to you? Kindest regards, Sean Suggested Resolution: 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 that includes several bindings for metadata retrieval services, they should make it clear when any of these bindings will return the same metadata instance document as any of the other metadata bindings in that WSDL document. This is done so that the client may choose to retrieve the metadata document from only one binding for each unique metadata document and still be sure to retrieve all the available metadata from this service. To do this, the WSDL service name should reference a unique metadata instance document, and all metadata endpoint bindings contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. By retrieving one metadata port from each of the services a client is guaranteed to receive all of the metadata without retrieving duplicate metadata. In the case where the implementers are uncertain as to the uniqueness of the metadata instance documents, they should attempt to provide a separate service name for each metadata endpoint binding.. 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. Martin Senger 07/20/2004 09:36 AM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org Subject Re: #issue 7569 > The sample WSDL files would be changed (you have the changed files from my > last note) > I am confortable to have this newq Sample file. But the text should be clearer (even though now I think I understand the point): > Where possible the WSDL service name should... > I would start "from the other side of the problem. Something like this: --- begin --- An LSID Resolution service provider - if it provides WSDLs for data retrieval services, any of them with several bindings for the same metadata - should make clear that each of these bindings will deliver the same metadata, so the client can choose only one binding and still be sure that it gets all metadata available from this particular data retrieval service. This can be achieved by... (and here you can continue similarly what you have in your suggeste resolution). In the case where the Resolution service provider is uncertain as to the uniqueness of the metadata provided by individual bindings, he should attempt to provide a separate service names for each metadata endpoint binding. --- end --- Such text seems to be more understandable. But of course, I am not an English-native speaker so I ma be completely wrong. Also I am personally uncertain that the second paragraph in the text above is really necessary. I tent to suggest to remove it and not to mention what to do in such case (we may end up in the conformace issue again). Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 20 Jul 2004 16:30:17 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org Subject: Re: #issue 7569 text updated X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) Sounds reasonably. Perhaps there are some typos - actually, quite a lot of rather language issues (which I am obviously not an expert - so please take my suggestions rather as hints): > ?When a Life Science Identifier Resolution service provider prepares a > WSDL response that includes several bindings for metadata retrieval > services, they should make it clear when any of these bindings will return | shouldn't it be '[s]he' instead of 'they'? > the same metadata instance document as any of the other metadata bindings | I would remove the word 'instance', perhaps even the word 'document'... > in that WSDL document. | this four words should probably go after 'make it clear', perhaps even in parenthesis ? > This is done so that the client may choose to > retrieve the metadata document from only one binding for each unique > metadata document > Well, the wording is strange: it says "retrieve the metadata document...for each unique metadata document". > and still be sure to retrieve all the available metadata > from this service. > > To do this, the WSDL service name should reference a unique metadata > instance document > The term "WSDL service name"? Perhaps "the WSDL should define more services (with different names) each of them referencing a unique metadat document". > and all metadata endpoint bindings contained in that service would be > duplicates. > term "endpoint bindings" - our spec uses WSDL1.1 so let's use 'port' and not 'endpoint' (which is for WSDL2.0); also the English does not sound correct: it says actually that "bindings...would be duplicates" - but you want to say "metadata retrievd by these bindings will be duplicates". Am I right? I stop here - perhaps you can also review the rest (e.g. is "retrieving one metadata port" correct? are we retrieving port or metadata?) Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: Martin Senger Cc: lsr-identifiers-ftf@omg.org Subject: issue #7569 text updated once more X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 13:57:15 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/20/2004 13:57:17, Serialize complete at 07/20/2004 13:57:17 Does this seem more like it? Kindest regards, Sean Issue 7569: Metadata ports are ambiguous in WSDL Summary: 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 Resolution: 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 that includes several bindings for metadata retrieval services, it should make it clear in that WSDL document, when any of these bindings will return the same metadata document as any of the other metadata bindings. This is done so that the client may choose to retrieve the metadata document from only one binding for each unique metadata document and still be sure to retrieve all the available metadata from this service. To do this, the WSDL should define more services (with different names) so that each service name can reference a unique metadata document, and all metadata documents retrieved from ports contained in that service would be duplicates. This one to one mapping between a service name and metadata groups duplicate metadata ports into individual services. A client is guaranteed to receive all of the metadata, without retrieving duplicate metadata, by retrieving a metadata document using one port from each of the services. In the case where the implementers are uncertain as to the uniqueness of the metadata documents, they should attempt to provide a separate service name for each metadata port.. 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. Martin Senger 07/20/2004 11:30 AM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org Subject Re: #issue 7569 text updated Sounds reasonably. Perhaps there are some typos - actually, quite a lot of rather language issues (which I am obviously not an expert - so please take my suggestions rather as hints): > ?When a Life Science Identifier Resolution service provider prepares a > WSDL response that includes several bindings for metadata retrieval > services, they should make it clear when any of these bindings will return | shouldn't it be '[s]he' instead of 'they'? > the same metadata instance document as any of the other metadata bindings | I would remove the word 'instance', perhaps even the word 'document'... > in that WSDL document. | this four words should probably go after 'make it clear', perhaps even in parenthesis ? > This is done so that the client may choose to > retrieve the metadata document from only one binding for each unique > metadata document > Well, the wording is strange: it says "retrieve the metadata document...for each unique metadata document". > and still be sure to retrieve all the available metadata > from this service. > > To do this, the WSDL service name should reference a unique metadata > instance document > The term "WSDL service name"? Perhaps "the WSDL should define more services (with different names) each of them referencing a unique metadat document". > and all metadata endpoint bindings contained in that service would be > duplicates. > term "endpoint bindings" - our spec uses WSDL1.1 so let's use 'port' and not 'endpoint' (which is for WSDL2.0); also the English does not sound correct: it says actually that "bindings...would be duplicates" - but you want to say "metadata retrievd by these bindings will be duplicates". Am I right? I stop here - perhaps you can also review the rest (e.g. is "retrieving one metadata port" correct? are we retrieving port or metadata?) Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 20 Jul 2004 19:07:37 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Tom Oinn Subject: Re: issue #7569 text updated once more X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) > Does this seem more like it? > Well, I have no more suggestions for text changes. But I still believe that it could be said better. After our discussion I understand what it is about but I do not feel comfortable with the wholw wording. Just one last try. I am cc-ing this to Tom Oinn who is both familiar with the LSID spec and with the web services generally. If he understands what the suggested resolution is about, it will satisfy me. Tom, could you read it please (just the text in Suggested Resolution - I have kept the summary in order you to know what was the issue)? > Issue 7569: Metadata ports are ambiguous in WSDL > Summary: > 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 Resolution: > 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 that includes several bindings for metadata retrieval > services, it should make it clear in that WSDL document, when any of these > bindings will return the same metadata document as any of the other > metadata bindings. This is done so that the client may choose to retrieve > the metadata document from only one binding for each unique metadata > document and still be sure to retrieve all the available metadata from > this service. > > To do this, the WSDL should define more services (with different names) so > that each service name can reference a unique metadata document, and all > metadata documents retrieved from ports contained in that service would be > duplicates. This one to one mapping between a service name and metadata > groups duplicate metadata ports into individual services. A client is > guaranteed to receive all of the metadata, without retrieving duplicate > metadata, by retrieving a metadata document using one port from each of > the services. In the case where the implementers are uncertain as to the > uniqueness of the metadata documents, they should attempt to provide a > separate service name for each metadata port.? > Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD X-Sender: andyp@ussfex01.bea.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 26 Jul 2004 08:34:43 -0700 To: Simon Nash From: Andy Piper Subject: Wire format for java.lang.reflect.Proxy classes v2 Cc: java2idl-rtf@omg.org, little@bea.com, ravia@bea.com So taking everyone's suggestions into account it seems like the following might be ok: Proxy instances will be marshalled using the following data structure: package javax.rmi.CORBA; /** * This class is used to marshal java.lang.Proxy objects over IIOP. */ public class ProxyDesc implements java.io.Serializable { /** * @serial The class names of the interfaces that the Proxy object * implements. */ public String[] interfaces; /** * @serial A space-separated list of codebase URLs. */ public String codebase; /** * @serial The Proxy's InvocationHandler instance. */ public java.lang.reflect.InvocationHandler handler; static final long serialVersionUID = 1234286961190911798L; } The Proxy class will be instantiated using the Util.loadProxyClass() method defined as follows: /** * Loads a dynamic proxy class (see {@link java.lang.reflect.Proxy}) * that implements a set of interfaces with the given names * from a codebase URL path. * *

The interfaces will be resolved similar to classes loaded via * the {@link #loadClass(String,String,ClassLoader)} method using the given * codebase. * *

This method delegates to the * {@link UtilDelegate#loadProxyClass(String,String[],ClassLoader)} * method of the provider instance, passing codebase * as the first argument, interfaces as the second argument, * and defaultLoader as the third argument. * * @param codebase the list of URLs (space-separated) to load * classes from, or null * * @param interfaces the names of the interfaces for the proxy class * to implement * * @param defaultLoader additional contextual class loader * to use, or null * * @return a dynamic proxy class that implements the named interfaces * * @throws ClassNotFoundException if a definition for one of * the named interfaces could not be found at the specified location, * or if creation of the dynamic proxy class failed (such as if * {@link java.lang.reflect.Proxy#getProxyClass(ClassLoader,Class[])} * would throw an IllegalArgumentException for the given * interface list) */ public static Class loadProxyClass(String codebase, String[] interfaces, ClassLoader loader) throws ClassNotFoundException; which shall delegate to the UtilDelegate implementation of the same method defined as follows: /** * Provides the implementation for * {@link Util#loadProxyClass(String,String[],ClassLoader)}. * * Loads a dynamic proxy class (see {@link java.lang.reflect.Proxy} * that implements a set of interfaces with the given names * from a codebase URL path, optionally using the supplied loader. * *

An implementation of this method must either return a proxy * class that implements the named interfaces or throw an exception. * * @param codebase the list of URLs (space-separated) to load * classes from, or null * * @param interfaces the names of the interfaces for the proxy class * to implement * * @return a dynamic proxy class that implements the named interfaces * * @param defaultLoader additional contextual class loader * to use, or null * * @throws ClassNotFoundException if a definition for one of * the named interfaces could not be found at the specified location, * or if creation of the dynamic proxy class failed (such as if * {@link java.lang.reflect.Proxy#getProxyClass(ClassLoader,Class[])} * would throw an IllegalArgumentException for the given * interface list) */ public Class loadProxyClass(String codebase, String[] interfaces, ClassLoader loader) throws ClassNotFoundException; Thoughts? Would Util and UtilDelegate need to be versioned to support this? Or would we just require that ORBs that support Proxy marshalling should support the new Util functions. Thanks andy Date: Thu, 22 Jul 2004 14:01:49 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Tom Oinn Subject: Re: issue #7569 text updated once more X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) It seems that we are still waiting for my final opinion on this issue. I know that Tom is quite busy - so if he cannot reply later today, I will express my opinion at the end of today (but I still hope that he can make it :-)). Cheers, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: lsr-identifiers-ftf@omg.org Cc: Tom Oinn , Martin Senger Subject: issue #7569 text updated one more time X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Thu, 22 Jul 2004 13:26:08 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/22/2004 13:26:24, Serialize complete at 07/22/2004 13:26:24 Much better. Thanks Tom. Here is the entire text of the suggested resolution for #7569. One we have agreement on this one I will send out the vote for all issues. Kindest regards, Sean Summary: 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 Resolution: 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 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 metadata ports 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. Date: Thu, 22 Jul 2004 18:41:26 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Tom Oinn Subject: Re: issue #7569 text updated one more time X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) It seems that we are approaching the consensus. That's good. I have very little to add to Tom's reply. Perhaps just these: * Let's not use CAPITALIZED words, we do not do it anywhere in the spec. * I would keep style as Tom put it - meaning to make individual "policies" as bullets, not paragraphs. * "a client can then ensure" should be rather (I think) "a client can then be ensured" * perhaps replace "whether metadata ports" with someting like "whether metadata" (I hope I am saying the same but without the confusing word 'port') Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger To: Martin Senger Cc: lsr-identifiers-ftf@omg.org, Tom Oinn Subject: issue #7569 text updated, another one more time X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Thu, 22 Jul 2004 14:10:49 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/22/2004 14:10:52, Serialize complete at 07/22/2004 14:10:52 Hi Martin, I made the changes you suggested apart from "can ensure" which is fine in English. Kindest regards, Sean Suggested Resolution: 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 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. Martin Senger 07/22/2004 01:41 PM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org, Tom Oinn Subject Re: issue #7569 text updated one more time It seems that we are approaching the consensus. That's good. I have very little to add to Tom's reply. Perhaps just these: * Let's not use CAPITALIZED words, we do not do it anywhere in the spec. * I would keep style as Tom put it - meaning to make individual "policies" as bullets, not paragraphs. * "a client can then ensure" should be rather (I think) "a client can then be ensured" * perhaps replace "whether metadata ports" with someting like "whether metadata" (I hope I am saying the same but without the confusing word 'port') Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Thu, 22 Jul 2004 19:18:52 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Tom Oinn Subject: Re: issue #7569 text updated, another one more time X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=0, required 5) Fine with me; thanks to all for their patience. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger +1 608 213 2867