W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > February 2007

RE: New interchange results

From: Jonathan Marsh <jonathan@wso2.com>
Date: Fri, 16 Feb 2007 10:41:43 -0800
To: "'Arthur Ryman'" <ryman@ca.ibm.com>
Cc: <public-ws-desc-comments@w3.org>
Message-ID: <00e601c751fa$1c204820$3501a8c0@DELLICIOUS>
Thank you for the comment.  The Working Group this issue as a CR126 [1] and
added text to that effect in the latest editor's draft [2].


Unless you let us know otherwise within 2 weeks, we will assume you agree
with the resolution of this issue.


[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR126 



Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com



From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Thursday, November 30, 2006 8:03 AM
To: Youenn Fablet
Cc: Jonathan Marsh; www-ws-desc@w3.org; www-ws-desc-request@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.


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 


Jonathan Marsh <jonathan@wso2.com> 




Re: New interchange results




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

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


Jonathan Marsh wrote:
> Thanks, lots more green at
> nge.html!
> See inline.
> Jonathan Marsh - http://www.wso2.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,
> ModuleComposition-1G, on soapHeaderBlockComponent and
>> 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
> required extensions or extended MEPs - in both cases the interchange can
> 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
> 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
Received on Friday, 16 February 2007 18:41:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:31:06 UTC