RE: Query parameter separator value

"Jonathan Marsh" <[email protected]>
Newsgroups gmane.comp.web.services.description
Message-ID <011d01c75768$06e1dff0$1501010a@DELLICIOUS>


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

> -----Original Message-----
> From: Youenn Fablet [mailto:[email protected]]
> 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\-\._~!$&amp;'\(\):@/\?\*\+,;]{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: [email protected] [mailto:[email protected]] 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
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.