Re: New interchange results

Thanks,
I fixed some bugs in the wsdl processor and the wsdl interchange 
generator (see attachment for results).
It seems that there is one document which has still issues 
(MessageTest-1G) when I am running locally the diff tool, although this 
document is equivalent to the one I sent last week and which appeared 
correct on 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results/Interchange.html.
This may be due to ordering of the binding fault references or 
differences in the stylesheet processors.
I am not sure of the ordering key there since these components only 
contain id and ref information.

Concerning the required extensions documents, I am not sure to 
understand your suggestion.
When an extension is set as optional, we can safely ignore it and assume 
that the component model is correct (even if not entirely complete, some 
properties might be missing).
When an extension is mandatory and we do not understand it, we cannot 
make this assumption and we do not know the impact of this extension on 
the component model : a required extension may well modify existing WSDL 
2.0 component property values.
Consequently, at least in our implementation, we are not able to 
generate a full component model when unknown required extensions are 
present.
Are you suggesting that we should generate the interchange on these 
documents either:
    - by ignoring these required extensions or
    - by adding in the interchange document information on these 
required extensions
    - a third option?  

    Youenn


Jonathan Marsh wrote:
> Thanks, lots more green at
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results/Intercha
> nge.html!
>
> See inline.
>
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
>   
>> -----Original Message-----
>> From: Youenn Fablet [mailto:youenn.fablet@crf.canon.fr]
>> Sent: Wednesday, November 22, 2006 3:04 AM
>> To: Jonathan Marsh
>> Cc: www-ws-desc@w3.org
>> Subject: New interchange results
>>
>> Please find updated canon interchange results.
>> These results should integrate  the latest interchange schema fixes and
>> include the newly added wsdl test-cases.
>> I hope all generated interchange documents are now schema valid.
>>     
>
> Not quite!  I show some duplicate IDs in MessageTest-1G, MessageTest-5G, and
> ModuleComposition-1G, on soapHeaderBlockComponent and soapModuleComponents.
>
>   
>> Please find below some issues:
>>
>> 1) I am still not able to have results for two files:
>>     - Echo-2G: it has a required unknown extension and uses meps that
>> are now in the separate W3C note.
>>     - WSAddressing1-G: it has the wsa required extension that we do not
>> support.
>> What should we do with these test cases?
>>     
>
> As far as the interchange format is concerned, there isn't any problem with
> required extensions or extended MEPs - in both cases the interchange can be
> generated just fine, even when the component model can't be correctly used
> further downstream.  I do see a problem with comparing results between an
> implementation that does support those extensions, but so far we don't have
> that problem!
>
> If however your implementation doesn't separate these cases, we can simply
> indicate that in our results, showing that it's simply a limitation of our
> test methodology rather than of the spec.
>
>   
>> 2) I also have a problem with MessageTest-2G: the schema document uses
>> the type 'IntFaultStruct' without defining it.
>> This type is also used and defined in MessageTest-1G.
>> I assume the type definition from MessageTest-1G should be copied in
>> MessageTest-2G.
>> Jonathan, can you update this schema document?
>>     
>
> Done.
>
>   
>> 3) It seems that the interchange canonicalization is not reordering the
>> message and fault references within interface/binding operations.
>> This leads to differences between the baseline and some canon
>> interchange documents which are not meaningful.
>> Jonathan, can you add the reordering in the canonicalization stylesheet
>> and rerun the comparisons?
>>     
>
> I fixed some issues with this at the FTF, which I think must have worked
> because I'm not seeing any failures because of ordering issues.  Maybe
> you've got an old version.
>
> However, I also improved the comparison results to give the nearest xml:id
> value - that helps narrow down just where the problem is more quickly.
> Should have done that long ago.
>
> Checking in all the above fixes shortly...
>
>   
>> Thanks,
>>     Youenn
>>
>>     
>
>
>
>