Issue 7388: how to use/implement LSIDs on top of existing databases (lsr-identifiers-ftf) Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger@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: End of Annotations:===== s is issue # 7388 how to use/implement LSIDs on top of existing databases It would be useful if the spec clarifies in text how to use/implement LSIDs on top of existing databases without changing their internal 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: Suggest we add the following text. "In general, the Life Science 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 Science Identifier authority is serving as a translator between the legacy database retrieval protocol and the Life Science Identifier resolution protocol. The 'namespace' and 'object' sections of the Life Science 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 Science Identifer.The Life Science Identifier authority can then extract the locator from a Life Science 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 Science 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." 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 #7388 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 08:26:34 -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>> Attached an update with changes to everything (including a spell check:-) SJM>> MS>Issue 7388 seems to have still typos. "Object identifier" is used with MS>different case sensitivity, it shoul be consistent with namespace and MS>authority. Also it should refer to "identification" (and not identifier) - MS>as used in chapter 8 (LSID Syntax). Also I do not like term "resolution MS>protocol" - this term is not used in the spec anywhere - reslotution MS>service would be more appropriate. And finally, I definitely do not like MS>wording "there are already numerous examples...widely available" - unless MS>it is supported by some references. Corrected as you suggest. Text for resolution now reads: 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 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." :wq Date: Tue, 20 Jul 2004 13:39:07 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi , Subject: Re: issue #7388 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.212, required 5, SUBJ_HAS_UNIQ_ID 0.21) Fine with me; thanks. 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-Server-Uuid: 48764CE8-FD0B-4606-A1C3-503FAD0548C7 From: "Miller, Michael (Rosetta)" To: "'Sean Martin'" , lsr-identifiers-ftf@omg.org cc: "Michael Niemi" , senger@ebi.ac.uk Subject: RE: lsr-identifiers-ftf - proposals for issue resolution III ( pl ease discuss!) Date: Mon, 19 Jul 2004 15:41:19 -0700 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6CE292711FK66182-01-01 Hi Sean, Thanks for the update. I appreciate the update to the wording for Issue 7388, it makes it clear that ultimately the implementer can decide. (from Jordi) "The comment about Timestamp being in an ISO standard format is problematic with my understanding. Doesn't that make it too specific with regard to a platform? For instance, an HTTP GET PSM model might want one format while the SOAP PSMs will likely want a different format. XML dates are a different format than HTTP header " Since the Timestamp is a String, the implementers have their choice of formats for that String that they will translate it as. As a user who will use one or more of these services, I would not want to vary how I have to read the date in the Metadata_response { string provided_format; Timestamp expiration_date; Metadata_document metadata; } structure when I query different implementations. But I might be missing the usage point here. cheers, Michael -----Original Message----- From: Sean Martin [mailto:sjmm@us.ibm.com] Sent: Monday, July 19, 2004 2:11 PM To: lsr-identifiers-ftf@omg.org Cc: Michael Niemi; senger@ebi.ac.uk; Miller, Michael (Rosetta) Subject: lsr-identifiers-ftf - proposals for issue resolution III ( please discuss!) Hi All, Attached an update with changes to everything (including a spell check:-) for most points raised in the last round -- the exceptions are the timestamp and WS-I issues. Jordi has the following comment to share (below). I would appreciate your comments/reactions here asap. I particularly liked his suggestion that we try to make ourselves WS-I compliant if he thinks it possible. If no one disagrees I will make the changes. Martin, one thing that I noticed in the draft spec. There are a number of places in the document (Sections 1, 3, 4, 5 - Scope, Normative references, Terms and Definitions, Symbols) that we either need to define or removed. The note says "Needs to be completed by the FTF". Any suggestions on how to handle each of these? Also attached for your perusal, copies of the latest WSDL files. The first was modified to illustrate the convention of placing duplicate metadata port in the same service. The second had a bug fixed where a namespace decleration was missing, the third is unchanged from when last I sent it. Kindest regards, Sean -- Sean Martin IBM Corp. ----- Forwarded by Sean Martin/Cambridge/IBM on 07/19/2004 04:04 PM ----- Jordi A Albornoz/Cambridge/IBM 07/19/2004 11:10 AM To Sean Martin/Cambridge/IBM@IBMUS cc Subject Re: Fw: lsr-identifiers-ftf - proposals for issue resolution II ( ple se discuss!)Link My thoughts: The comment about Timestamp being in an ISO standard format is problematic with my understanding. Doesn't that make it too specific with regard to a platform? For instance, an HTTP GET PSM model might want one format while the SOAP PSMs will likely want a different format. XML dates are a different format than HTTP header dates, as a concrete example. Again, I am not well versed in the interpretation of OMG-style platform independent models, but there would have to leave room for using other formats for some PSMs for it to be correct in my case. I'm not sure if that is the case even when the format is specified in the PIM. The comment about explicitly stating that if you use base64, then you are not WS-I compliant, I agree with. We were going to put it in but at our meeting by the cubes the consensus was that it was unneeded. If they are insisting, I have no problem with it. The solution would involve adding the following sentences: "Implementations that choose to send base64 encoded data within the SOAP messages rather than using attachments are not 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 does not conform to the relevant WSDL are not WS-I compliant." Also, I just realized that maybe it is a good idea to make this explicit and thus conform to the WS-I. We can talk more about this but basically, we can add one more WSDL SOAP binding so that we end up with 2 SOAP choices....the efficient attachments one and the inefficient, transitional base64 one. Then both would be explicitly defined and interoperability would cease to be a problem as both would be WS-I compliant. It would be up to the client/server to implement whichever they like or both...just like with HTTP bindings....it's simply another choice. I think that is actually a good way to do this...better that simply letting people figure out how to do base64 themselves without any explicit description of it. But it also might not be neccesary. What to you think? --Date: Tue, 20 Jul 2004 00:31:05 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi , Michael_Miller@rosettabio.com Subject: Re: lsr-identifiers-ftf - proposals for issue resolution III ( 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) > Attached an update with changes to everything (including a spell check:-) > for most points raised in the last round > I will look at it (and comment on it) later when I boot to Windoze (Sean, you are not making my life easier :-)). > Martin, one thing that I noticed in the draft spec. There are a number of > places in the document (Sections 1, 3, 4, 5 - Scope, Normative references, > Terms and Definitions, Symbols) that we either need to define or removed. > The note says "Needs to be completed by the FTF". Any suggestions on how > to handle each of these? > Yes, I forgot to comment on it earlier. I would say: * Scope... ignore it (keep this chapter as it is now) * Normative references ... remove the chapter * Terms and definitions ... remove the chapter * Symbols ... remove the chapter This is the first time I see these chapters included. So my suggestion is just my opinion - but I would put a small capter in the report saying that the following are editorial changes that are suggested by this FTF without being raised as the real issues. > Also attached for your perusal, copies of the latest WSDL files. > Again, I will look at it later; it's too late here now... > The comment about Timestamp being in an ISO standard format is problematic > with my understanding. > What is problematic with saying: "It should be ISO... unless a PSM is using another well establish format tied with that particular platform."? And that is what I have suggested. So where is the problem? > The comment about explicitly stating that if you use base64, then you are > not WS-I compliant > Again, where is the problem? We are saying "do it WS-I - so use attachements; but because there may be lack of existing tools supporting attachements, do it as base64 if you must". What's wrong with this? > Also, I just realized that maybe it is a good idea to make this explicit > and thus conform to the WS-I. > Only if we can withdraw the fact about the lack of existing tools. Is it, after all, truth? Are there missing tools? > we can add one more WSDL SOAP binding so that we end up with 2 SOAP > choices....the efficient attachments one and the inefficient, transitional > base64 one. Then both would be explicitly defined and interoperability > would cease to be a problem as both would be WS-I compliant. > I do not think that we can add a new bindings - it would be perhaps too much to get it through (the FTF is for making changes necessary for implementtaion, but not for adding new features). -- 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 00:33:39 +0100 (BST) From: Martin Senger To: "Miller, Michael (Rosetta)" cc: "'Sean Martin'" , lsr-identifiers-ftf@omg.org, Michael Niemi Subject: RE: lsr-identifiers-ftf - proposals for issue resolution III ( pl ease 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) > I would not want to vary how I have to read the date in the ... > structure when I query different implementations. > The spec (and the suggested resolutions) says precisely how to read the date. It just happens that it differs from platform to platform (but not within platform). 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 00:48:30 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org, Michael Niemi , Michael_Miller@rosettabio.com Subject: Re: lsr-identifiers-ftf - proposals for issue resolution III ( 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) > Attached an update with changes to everything (including a spell check:-) > Issue 7388 seems to have still typos. "Object identifier" is used with different case sensitivity, it shoul be consistent with namespace and authority. Also it should refer to "identification" (and not identifier) - as used in chapter 8 (LSID Syntax). Also I do not like term "resolution protocol" - this term is not used in the spec anywhere - reslotution service would be more appropriate. And finally, I definitely do not like wording "there are already numerous examples...widely available" - unless it is supported by some references. > the exceptions are the timestamp and WS-I issues. > ...and 7569, of course (metadata duplicates); I am studying now the WSDL you sent us. 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 09:13:13 +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 III ( 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) > Also attached for your perusal, copies of the latest WSDL files. The first > was modified to illustrate the convention of placing duplicate metadata > port in the same service. > Please correct me here: you are saying that only the sample wsdl is going to be changed (if we agree on this issue), but not the WSDL specification itself? > The second had a bug fixed where a namespace > decleration was missing > You can either "squeeze" this change under an existing issue (for example under the issue correcting 'ibm' to 'omg'), or raise a separate issue. Otherwise, the change itself is reasonable and I have no comment on it. So, time is running and I think we should vote on atleast those issues that are clear - the emails will be then shorter :-) (Btw, my last day in the office is one week from today - later I cannot vote being at BOSC in Glasgow). I am still not sure mainly about the metadata duplicate issue - it worries me. The WS-I and Timestamp seem to need only clarification among ourselves - but I do not see there any big problem. 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 schemata.