Re: ';' parameter in segments

At 07:27 AM 2002-02-28 , Stefan Eissing wrote:
>RFC 2396 defines parameters in segments of hierarchical uris.

RFC 2396 defines syntax allowing parameters in segments in hierarchical paths in URIs.

It does not define the parameters.

Your service model must define the parameters.

Have you considered putting your service parameters in a SOAP envelope where you have a straightforward way to back them up with a schema?

>For my own uri class hierarchy I'm having a syntactically
>correct implementation, passing all tests defined in 2396,
>however I am at loss to how give users of my API access to
>this information. This of courses touches on semantic issues
>regarding these parameters:
>
>http://host/seg1/seg2;param
>and
>http://host/seg1/seg2?param
>
>are not equal, I assume. Can/should/must both refer to the
>same resource?

Can be same?  In the following sense:  Exercising them could always have the same effect.  
Whether this makes the associated resources one and the same is not so easy to get agreement on.

Should both refer to the same resource?  Personal answer: no.  This answer probably gets pretty good support.

Must both refer to the same resource?  Expected unanimous answer:  no.

Shou>
>How do
>
>http://host/seg1/seg2;param
>and
>http://host/seg1;param/seg2
>and
>http://host/seg1/seg2
>
>relate to each other (if at all)?
>
>Or, asking the other way around: What is the difference
>between the following two uris:
>
>http://host/seg1;param/seg2
>and
>http://host/seg1%3bparam/seg2
>

There is a generic URI assertion about this last pair.

The first of this pair generates two syntactically recognized children from the path segment next after the host.  The second generates one, containing an embedded reserved character.  The second URI does not match the 'parameter' production in the grammar and passes through un-divided.

But beyond that it is up to you as the service offeror.  Don't expect HTTP to tell you.

>Is there a generic uri view on these examples or is it
>merely an issue for HTTP (or whatever other hierarchical
>scheme is used) to resolve?
>

It is for your service to resolve on receipt of a request.

The path syntax allows you to bind protocol parameters by positional association.  The searchpart syntax following the ? allows you to bind protocol parameters by named association (without regard to order).  The ;parameter syntax allows you to elaborate on values, expecially of positionally associated protocol parameters with qualifying expressions.

Parameters appearing before the ? qualify the path segment that they appear in (nominally).  Parameters appearing after the ? qualify the whole URI.  But the functional effect is entirely at the disposal of the service accessed, and the same effect can be obtained in either syntax by determinedly obscure programming.  Without violating the URI syntax.

But what all those protocol parameters mean is up to your service offering.

HTH


Al
>Best Regards, Stefan
>

Received on Thursday, 28 February 2002 16:59:55 UTC