+1 Arthur Ryman, PhD, AoT, DE Process and Portfolio Management, Rational Division phone: +1-905-413-3077, TL 969-3077 assistant: +1-905-413-3831 (T/L: 318-8867) fax: +1-905-413-4920, TL 969-4920 mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
"Jonathan Marsh" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 05/08/2007 02:13 PM To "'John Kaputin \(gmail\)'" <[EMAIL PROTECTED]>, "'WS-Description WG'" <[EMAIL PROTECTED]> cc <[email protected]> Subject RE: Is an assertion required for {http location} EBNF grammar? +1 from me. Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Kaputin (gmail) Sent: Tuesday, May 08, 2007 9:02 AM To: WS-Description WG Cc: [email protected] Subject: Re: Is an assertion required for {http location} EBNF grammar? I'd like to propose replacing the text associated with the EBNF grammar in section 6.8.1.1: "The following EBNF [ISO/IEC 14977:1966] grammar represents the patterns for constructing the request IRI" with the new assertion HTTPSerialization-2106: "The {http location} property MUST conform to the following EBNF [ISO/IEC 14977:1966] grammar, which represents the patterns for constructing the request IRI." regards, John Kaputin. On 5/4/07, John Kaputin (gmail) <[EMAIL PROTECTED]> wrote: There is no WSDL assertion stating that an {http location} or whttp:location must conform to the EBNF grammar defined in Part 2 Section 6.8.1.1. Consider the following whttp:location values, which do not conform to this EBNF grammar: "/to}wn/{localname}" (unmatched left brace) "/town/{local:name}" (template does not specify an NCName) "/town/{localname" (closing right brace is missing) Should these be considered WSDL errors? If so, should there be an assertion about the EBNF grammar? Apache Woden parses the whttp:location attribute and if it does not conform to the EBNF grammar the {http location} property is flagged as invalid, but there is no WSDL assertion to use for error reporting. Alternatively, Woden could just ignore these grammar errors and treat them as ordinary string content in {http location} but the problem would still need to be resolved when the request IRI is constructed by the message builder. John Kaputin.
<<image/jpeg>>
