RE: Interop tests

["Campana Jr., Salvatore J" <sal.campana@hp.com>]

I think I am ready to expose, I am just waiting to hear from Rick on the
last issues... 

-----Original Message-----
From: Tim Banks [mailto:tim_banks@uk.ibm.com] 
Sent: Tuesday, March 08, 2005 12:00 PM
To: Rick Rineholt; Campana Jr., Salvatore J
Cc: wsrf@lists.oasis-open.org
Subject: Interop tests





Hi Rick/Sal,

It seems to me that the request  described in the scenario document
(scenario B1) isn't valid wrt to the schema because the whitespace in
the job_hold_until_supported element is not supposed to be there. So,
taking whitespace out of the request is the right way to go.  There is a
'white space' disclaimer in section  1.2.  Sorry for the confusion!  I
guess that message is best left in the less readable, but more accurate
form: I'll update the document.

Sal: a) Thanks for your comments on the document. b) Are you ready to
advertise your endpoint on the mailing list? - It seems so to me : - )


Regards, Tim Banks
IBM TP Architecture & Technology. Hursley, UK.
Phone: External +44 1962 815639, Internal 245639

Rick Rineholt <rineholt@us.ibm.com> wrote on 04/03/2005 17:34:38:

>
> Hello,
> Thanks for the feedback,  I think I've addressed these now.  But the 
> with respect to the whitespace I'm not convinced as of yet  that what 
> was happening was incorrect. First 
> "setIgnoringElementContentWhitespace" does not resolve the issue.  I 
> tested this. And from my parse documentation:
> ... Note that only whitespace which is directly contained within 
> element content that has an element only content model will be
> eliminated.   ....
>
> But the element  contains text elements "No-Hold"  so I think the 
> parser not removing the whitespace is correct.
>
> The only way I got around this was to change the actual schema used to

> : <xsd:pattern value="[ \t\n\r]*No-Hold[ \t\n\r]*" />
>
> But this is not TRUE to the original schema and I'm still not 
> convinced that throwing the fault with the original schema as given 
> was incorrect. BTW this is  xerces xml parser and not our code 
> directly that is issuing this.
>
> Tim,
> Maybe we have here our first interoperability issue ... do you plan on

> determining what the correct response or record it for the WS-RF TC ?
>
> Rick Rineholt
> "The truth is out there...  All you need is a better search engine!"
>
> rineholt@us.ibm.com
>
>

>
> "Campana Jr., Salvatore J" <sal.campana@hp.com>
> 03/03/2005 15:51
>
> To
>
> "Campana Jr., Salvatore J" <sal.campana@hp.com>, Rick 
> Rineholt/Raleigh/IBM@IBMUS, "Tim Banks" <tim_banks@uk.ibm.com>
>
> cc
>
> Subject
>
> RE: [wsrf] IBM WSRF Interoperability endpoint announcement.
>
>
>
>
> The reason I mention the white space issue, is that I am sure others 
> will hit that also.  You can probably set the parser to ignore 
> whitespace and all should be fine...
>
> -----Original Message-----
> From: Campana Jr., Salvatore J
> Sent: Thursday, March 03, 2005 3:49 PM
> To: 'rineholt@us.ibm.com'; 'Tim Banks'
> Subject: RE: [wsrf] IBM WSRF Interoperability endpoint announcement.
>
> Guys,
>
> I found two things while working with your endpoint...
>
> 1. InvalidInsertResourcePropertiesRequestContentFault is misspelled 
> (you return InvalidInsertResourceProperitesRequestContentFault...stare
> at it you will see ;-) ) ..I'm assuming someone wrote this by hand 
> since it is correct in the spec WSDL..
>
> 2. White space is not being handled.  The interop doc outlined 
> requests (See Scenario B3)...My requests look(ed) exactly like that, 
> white space and all and you fail with a parse exception.  Removing the

> space solved the issue.
>
> Other than that, you passed using my test harness....We should have 
> our endpoint exposed soon and I am looking forward to running your 
> client against my endpoint...nice work on that interface...
>
> -Sal
>
>
>
> -----Original Message-----
> From: rineholt@us.ibm.com [mailto:rineholt@us.ibm.com]
> Sent: Wednesday, March 02, 2005 8:50 AM
> To: wsrf@lists.oasis-open.org
> Subject: [wsrf] IBM WSRF Interoperability endpoint announcement.
>
> The following URL http://wsi.alphaworks.ibm.com/ettk/wsrfrpio/ has all

> the information for the IBM endpoint participating in the WSRF 
> interoperability 2.0 event.
> Our current plans are to keep our endpoint available till March 18.