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:]
Sent: Tuesday, March 08, 2005 12:00 PM
To: Rick Rineholt; Campana Jr., Salvatore J
Cc:
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 <> 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!"
>
>
>
>
>
> "Campana Jr., Salvatore J" <>
> 03/03/2005 15:51
>
> To
>
> "Campana Jr., Salvatore J" <>, Rick
> Rineholt/Raleigh/IBM@IBMUS, "Tim Banks" <>
>
> 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: ''; '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: [mailto:]
> Sent: Wednesday, March 02, 2005 8:50 AM
> To:
> 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.
