- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Thu, 27 Apr 2006 12:09:39 -0400
- To: Youenn Fablet <youenn.fablet@crf.canon.fr>
- Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <OF638D8A3A.635EAB56-ON8525715D.00578B8E-8525715D.0058C5F8@ca.ibm.com>
*********************** Warning: Your file, documents.zip, contains more than 32 files after decompression and cannot be scanned. *********************** Youenn, I thought I fixed the xs:string problem which you previuosly reported. I'll doublecheck. Here is my view on the purpose of the testing effort. At this point we are really debugging the spec. It is reasonable for a given implementation to fail some tests. We are not certifying implementations. However, if no implementation can successfully implement some feature, then we need to understand why, and potentially alter the spec. Interoperability is one way to test the correctness of implementations since it is unlikely that they will possess bugs that precisely cancel eachother. Even if just one implementation implements a feature, we can visually inspect it for correctness. Arthur Ryman, IBM Software Group, Rational Division blog: http://ryman.eclipsedevelopersjournal.com/ phone: +1-905-413-3077, TL 969-3077 assistant: +1-905-413-2411, TL 969-2411 fax: +1-905-413-4920, TL 969-4920 mobile: +1-416-939-5063, text: 4169395063@fido.ca Youenn Fablet <youenn.fablet@crf.canon.fr> Sent by: www-ws-desc-request@w3.org 04/27/2006 11:49 AM To www-ws-desc@w3.org cc Subject Component Model Results *********************** Warning: Your file, documents.zip, contains more than 32 files after decompression and cannot be scanned. *********************** Hi all, I have just finished generating the component model dumps of the wsdl good documents. I just picked the test-suite.xml file and generated my test script through XSLT. Fairly quick in fact :-) Please find attached the results. Two side notes: - There is still a problem with 3 testsuite wsdl files (SchemaLocationFragment-1G/Items.wsdl, XSImport-2G/reservationItems.wsdl, XSImport-3G/reservationItems.wsdl). All of these files make reference to XSD data types through QNames but with a wrong namespace. I have fixed these files locally (type="string" is now type="xs:string") and produced a dump with these fixed files. I added the fixed wsdl files in the attached zip file. - Our implementation still fails on the Import-2G example as it raises an error when trying to create two components of the same type with the same ns+name, the reason being that we have not implemented the component equivalence rules. Anyway, the parser still produces a component model dump. I have a process question related to the last point: do we really need two interoperable implementations for every aspect of the spec, e.g. the equivalence rules ? Or is it sufficient to document the reasons behind different behaviors ? Hope this helps anyway, Regards, Youenn
Attachments
- application/zip attachment: documents.zip
Received on Thursday, 27 April 2006 16:10:15 UTC