Issue 7572: 'binary64' conformance claim (lsr-identifiers-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Issue: Section 13.2.2.1 mentions that implementors can use "binary64" encoding. This should either say "base64" encoding since that is the more accepted name for the encoding. Also, it should be explicitly noted that doing so will reduce the interoperability of the implementation significantly and that the resulting implementation will not be WS-I compliant. Suggested solution: Either remove this claim now that the attachments WS-I profile is further along, or at least explicitly note that the resulting implementation will not be WS-I compliant and might not be interoperable. Also, "binary64" should be changed to "base64". Resolution: see below Revised Text: The following applies to section 13.2.2.1: Change "binary64" should be changed to "base64". Add the following text to 13.2.2.1 as a new paragraph after the second paragraph ending in “….and still remain compliant with this specification” and before the new heading “Reporting errors”. "Note that implementations that choose to send base64 encoded data within the SOAP messages rather than using attachments will not be WS-I compliant. This is because the WSDLs explicitly say that attachments should be used and the WS-I profiles state that implementations that send messages that do not conform to the relevant WSDL are not WS-I compliant." Actions taken: July 9, 2004: received issue December 3, 2004: closed issue Discussion: End of Annotations:===== c: lsr-identifiers-ftf@omg.org, juergen@omg.org, Sean Martin Subject: Life Science Identifier Issue (lsr-identifiers-ftf) : 'binary64' conformance claim X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: Jordi A Albornoz X-MIMETrack: S/MIME Sign by Notes Client on Jordi A Albornoz/Cambridge/IBM(Release 6.0.1|February 07, 2003) at 07/09/2004 10:52:01 AM, Serialize by Notes Client on Jordi A Albornoz/Cambridge/IBM(Release 6.0.1|February 07, 2003) at 07/09/2004 10:52:01 AM, Serialize complete at 07/09/2004 10:52:01 AM, Itemize by Notes Client on Jordi A Albornoz/Cambridge/IBM(Release 6.0.1|February 07, 2003) at 07/09/2004 10:52:02 AM, S/MIME Sign complete at 07/09/2004 10:52:02 AM, S/MIME Sign by Notes Client on Jordi A Albornoz/Cambridge/IBM(Release 6.0.1|February 07, 2003) at 07/09/2004 10:53:33 AM, S/MIME Sign complete at 07/09/2004 10:53:33 AM, Serialize by Router on D01ML251/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/09/2004 10:53:27, Serialize complete at 07/09/2004 10:53:27 Date: Fri, 9 Jul 2004 10:53:25 -0400 Hello, Issue: Section 13.2.2.1 mentions that implementors can use "binary64" encoding. This should either say "base64" encoding since that is the more accepted name for the encoding. Also, it should be explicitly noted that doing so will reduce the interoperability of the implementation significantly and that the resulting implementation will not be WS-I compliant. Suggested solution: Either remove this claim now that the attachments WS-I profile is further along, or at least explicitly note that the resulting implementation will not be WS-I compliant and might not be interoperable. Also, "binary64" should be changed to "base64". -- Jordi Albornoz Internet Technology jordi@us.ibm.com 617-693-1278 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.1t: "It should be noted that if inline base64 is used, then the the implementation will no longer be WS-I compliant and may less interoperable. New implementations should use attachments conformant with the the latest WS-I profiles." Change "binary64" should be changed to "base64". 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: lsr-identifiers-ftf@omg.org Cc: Michael Niemi , Martin Senger , Michael_Miller@rosettabio.com Subject: issue #7572 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 09:06:51 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/20/2004 09:16:41, Serialize complete at 07/20/2004 09:16:41 Here follows the current text for #7572. The remaining issue is whether we addressed the part of it that reads "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." It sounds like Michael will be happy with the current resolution although he raises the point that we only addressed half the issue. Martin did not understand the concern Michael had (which was that we had not completely addressed the issue that was raised, having addressed only the first part (base64 not binary64). Hopefully it is clear now. So the question remains, should we add a sentence at the appropriate place (such as "It should be noted that by using binary64 the implementation will no longer be WS-I compliant and is therefore likely to be less interoperable.") or do we leave the suggested resolution as it is or do we add a note to the AB saying why we did not address this point in the issue? As for Jordi's suggestion about making it WS-I compliant by adding an extra SOAP binding, I agree with Martin's that this is probably beyond the scope of the FTF and must wait for an overall specification revision. -------------- Issue 7572: 'binary64' conformance claim Summary: Section 13.2.2.1 mentions that implementers 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 text to 13.2.2.1: Change "binary64" should be changed to "base64". To: lsr-identifiers-ftf@omg.org Cc: Michael Niemi , Martin Senger , Michael_Miller@rosettabio.com Subject: Further to issue #7572 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 20 Jul 2004 09:19:19 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 07/20/2004 09:32:43, Serialize complete at 07/20/2004 09:32:43 If we did add a couple of sentences, this one from Jordi is not too bad to add after the current discussion about base64 in the conformance section. ""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."" ----- Forwarded by Sean Martin/Cambridge/IBM on 07/20/2004 09:15 AM ----- Sean Martin/Cambridge/IBM 07/20/2004 09:06 AM To lsr-identifiers-ftf@omg.org cc Michael Niemi/Boca Raton/IBM@IBMUS, Martin Senger , Michael_Miller@Rosettabio.com Subject issue #7572Link Here follows the current text for #7572. The remaining issue is whether we addressed the part of it that reads "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." It sounds like Michael will be happy with the current resolution although he raises the point that we only addressed half the issue. Martin did not understand the concern Michael had (which was that we had not completely addressed the issue that was raised, having addressed only the first part (base64 not binary64). Hopefully it is clear now. So the question remains, should we add a sentence at the appropriate place (such as "It should be noted that by using binary64 the implementation will no longer be WS-I compliant and is therefore likely to be less interoperable.") or do we leave the suggested resolution as it is or do we add a note to the AB saying why we did not address this point in the issue? As for Jordi's suggestion about making it WS-I compliant by adding an extra SOAP binding, I agree with Martin's that this is probably beyond the scope of the FTF and must wait for an overall specification revision. -------------- Issue 7572: 'binary64' conformance claim Summary: Section 13.2.2.1 mentions that implementers 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 text to 13.2.2.1: Change "binary64" should be changed to "base64". Date: Tue, 20 Jul 2004 14:46:54 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org Subject: Re: issue #7572 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) > The remaining issue is whether we addressed the part of it that reads > "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." It sounds like > Michael will be happy with the current resolution although he raises the > point that we only addressed half the issue. > Well, we may address the second half by simply saying "issue ignored". We have right to do so. However, even though the spec already now clearly says what is "a preferable way" - I am fine with an additional text reminding people about further interoperability. So if you wish put there: > "It should be noted that by using binary64 the implementation > will no longer be WS-I compliant and is therefore likely to be less > interoperable." (But please change thare binary64 to base64 :-) 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 #7572 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 How is everyone with the following text? Martin note that the point about available toolkits is already in the preceding paragraph and therefore will still be fresh in the mind of the spec. reader. Suggested Resolution: The following applies to section 13.2.2.1: Change "binary64" should be changed to "base64". Add the following text to 13.2.2.1 as a new (third) paragraph after the second paragraph in that section ending in ...and still remain compliant with this specification. and before the new heading .Reporting errors.. "Note that implementations that choose to send base64 encoded data within the SOAP messages rather than using attachments will not be WS-I compliant. This is because the WSDLs explicitly specify that attachments should be used and the WS-I profiles state that implementations that send messages that do not conform to the relevant WSDL are not WS-I compliant." Martin Senger 07/20/2004 09:55 AM To Sean Martin/Cambridge/IBM@IBMUS cc lsr-identifiers-ftf@omg.org Subject Re: Further to issue #7572 > ""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."" > Sounds good. (Perhaps just put it in the context "why the implementations choose to send base64" - because there may not be avialable SOAP toolkits, etc, etc, as it is in the spec.) 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:12:06 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org Subject: Re: issue #7572 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) > How is everyone with the following text? > Sounds good to me. 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 X-Server-Uuid: 48764CE8-FD0B-4606-A1C3-503FAD0548C7 From: "Miller, Michael (Rosetta)" To: "'Martin Senger'" , "Sean Martin" cc: lsr-identifiers-ftf@omg.org Subject: RE: issue #7572 text updated. Date: Tue, 20 Jul 2004 08:49:07 -0700 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6CE3E16A1FK67934-01-01 and me also, Michael > -----Original Message----- > From: Martin Senger [mailto:senger@ebi.ac.uk] > Sent: Tuesday, July 20, 2004 8:12 AM > To: Sean Martin > Cc: lsr-identifiers-ftf@omg.org > Subject: Re: issue #7572 text updated. > > > > How is everyone with the following text? > > > Sounds good to me. > 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 14:55:21 +0100 (BST) From: Martin Senger To: Sean Martin cc: lsr-identifiers-ftf@omg.org Subject: Re: Further to issue #7572 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) > ""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."" > Sounds good. (Perhaps just put it in the context "why the implementations choose to send base64" - because there may not be avialable SOAP toolkits, etc, etc, as it is in the spec.) 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 smime1.p7s