Interop tests

[Tim Banks <tim_banks@uk.ibm.com>]

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.