RE: Query parameter separator value

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

> -----Original Message-----
> From: Youenn Fablet [mailto:youenn.fablet@crf.canon.fr]
> Sent: Friday, February 23, 2007 12:24 AM
> To: Jonathan Marsh
> Cc: 'Jean-Jacques Moreau'; 'www-ws-desc'
> Subject: Re: Query parameter separator value
> 
> Jonathan Marsh wrote:
> > The list of characters allowed [1] in a query (where the {http query
> > parameter separator} is utilized) is:
> >
> >    query         = *( pchar / "/" / "?" )
> >    pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
> >    unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
> >    pct-encoded   = "%" HEXDIG HEXDIG
> >    sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
> >
> sub-delims also contains: "*" / "+" / "," / ";" / "="

Oops, copy-paste error.  (Didn't want to disallow ";"!)

> "=" seems not right to me as it is already used to separate the
> parameter name from the parameter value.

Yeah, OK, I'll give you that.

> I am not quite sure about the implications with "+".
> > Compiling that down and factoring out % (which can't appear as a single
> > character without causing damage) we get:
> >
> >    ALPHA / DIGIT / "-" / "." / "_" / "~" / "!" / "$" / "&" / "'" /
> >    "(" / ")" / ":" / "@" / "/" / "?"
> >
> Adding at least "," and "*" might be a good idea.
> I am wondering whether "+" is a practical choice but it may be safer to
> include it.
> Otherwise, this list sounds good to me in the wsdl schema.

So the final list would be

  ALPHA / DIGIT / "-" / "." / "_" / "~" / "!" / "$" / "&" / "'" /
  "(" / ")" / ":" / "@" / "/" / "?" / "*" / "+" / "," / ";"

Here's my attempt at a schema pattern for that:

  [a-zA-Z0-9\-\._~!$&'\(\):@/\?\*\+,;]{1,1}

Untested!

> > I assume these are the query parameter separators that can be used
> > effectively.  If we were to restrict the value space of the
> > queryParameterSeparater attribute that's the list I would start with.
> >
> > ALPHA and DIGIT would be the first things I'd dump from the list, but
> I'm
> > not sure I want to start going down the path of deciding which of the
> > allowed characters are really useful.
> >
> +1
> A half-way solution would be, in addition to the schema tightening, to
> state that '&' and ';' are the most natural/used/interoperable options.

I'm fine with that too!

> 
> 
> > BTW, I recorded this as issue CR156 [1].
> >
> > [1] http://www.ietf.org/rfc/rfc3986.txt
> > [2] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR156
> >
> > Jonathan Marsh - http://www.wso2.com -
> http://auburnmarshes.spaces.live.com
> >
> >
> >
> >> -----Original Message-----
> >> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> >> Behalf Of Jean-Jacques Moreau
> >> Sent: Wednesday, February 21, 2007 7:41 AM
> >> To: Youenn Fablet
> >> Cc: www-ws-desc
> >> Subject: Re: Query parameter separator value
> >>
> >>
> >> Option 2 would be to add an assertion that the instance data MUST NOT
> >> contain the queryParameterSeparator.
> >>
> >> JJ.
> >>
> >> Youenn Fablet wrote:
> >>
> >>> Reading the specification, it seems that the only constraint on the
> >>> separator value is to be a xml string of length 1.
> >>> It would therefore be possible to have a separator value that needs to
> >>> be %-encoded in the URL (e.g. queryParameterSeparator="é").
> >>> I do not know whether that was intended but in this case, the query
> >>> string may become ambiguous: if the separator value appears in a
> >>> parameter value, it will be %-encoded exactly like the separator
> >>> value. It might be safer to restrict the separator value range.
> >>>
> >>> In any case, the most sensible values are '&' and ';'. Is there any
> >>> other obvious possibility?
> >>> While '&' is the default value, ';' does not appear AFAIKT neither in
> >>> the spec nor in the primer.
> >>> It might therefore be good to add a statement that tells a word about
> >>> these values, maybe as a SHOULD.
> >>> Regards,
> >>>    Youenn
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >

Received on Friday, 23 February 2007 16:31:00 UTC