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