Re: New interchange results

***********************
Warning: Your file, cm-canonresults-20063011.zip, contains more than 32 files after decompression and cannot be scanned.
***********************


Youenn,

Recall that the interchange format now declares the set of extensions that 
it has engaged. 

If an unengaged extension is encountered then two cases occur.

1. The extension is marked as wsdl:required="false" either explicitly or 
by default. In this case the component model is valid and omits all the 
extension properties and components.

2. The extension is marked as wsdl:required="true". In this case the 
component model is invalid. However, I just checked the spec and we don't 
spell this out. I think we need an issue.

Jonathan, I proposed we add an assertion:

A WSDL 2.0 document that contains a required unengaged extension is 
invalid.

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
11/30/2006 08:28 AM

To
Jonathan Marsh <jonathan@wso2.com>
cc
www-ws-desc@w3.org
Subject
Re: New interchange results






***********************
Warning: Your file, cm-canonresults-20063011.zip, contains more than 32 
files after decompression and cannot be scanned.
***********************


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