RE: Is an assertion required for {http location} EBNF grammar?

For the record, the WG resolved this issue [1] by accepting your proposal.
I've just fixed it in the XML source. [2]

 

Since you were present, we know you agree with this resolution.

 

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4550 

[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.xml 

 

 

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

 

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of John Kaputin (gmail)
Sent: Tuesday, May 08, 2007 9:02 AM
To: WS-Description WG
Cc: woden-dev@ws.apache.org
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) <jakaputin@gmail.com> 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.