Re: Component Model Results

Youenn,

Thx for the fixes to the test cases. They are committed now:

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


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


[attachment "documents.zip" deleted by Arthur Ryman/Toronto/IBM]