Re: [XML-URI] HTTP extensions framework comparison

At 09:24 19/07/00 -0700, Henrik Frystyk Nielsen wrote:

> > I just skimmed RFC 2774, and I don't think it mandates the use of http
> > URIs; so I take your statement to mean that, when an application is
> > searching extension declarations for something it knows how to process,
>it
> > must use the comparison rules in RFC 2616 if it is looking for http URI
> > names, and literal comparison otherwise.
>
>Nope, there is nothing specific to HTTP URIs in this. As I have mentioned
>before, it just so happens that HTTP URIs use all aspects of the URI
>syntax defined by RFC 2396 and so there is a 1:1 mapping between the
>equality rules defined for HTTP URIs and URIs and RFC 2396. It is more for
>historic reasons that anything else that those rules are explained in the
>HTTP spec and not in the URI spec.
>
>There is also no "must" for an application consuming a URI used to
>identify an extension to use any of these equality rules - the rules are
>
>* An application *generating* a name must follow the rules
>   from the space the name belongs to.
>
>* An application *consuming* a must at a minimum use case-sensitive
>   comparison but may apply specific URI scheme equality rules if it wants
>   to/knows about them.

Sorry, I don't understand how this applies to this particular 
situation.  Perhaps I'm being obtuse.  Let me make the question a bit more 
explicit -- suppose I define an extension header, say:

    Req: "http://www.informatix.co.uk/headers/"; ns=15
    15-getmd5: "yes"

which is defined (by me, I control this URI space) to cause the web server 
to return an MD5 checksum of the resource, rather than it's body.

Suppose a web server looks for this by doing a case sensitive string 
comparison with
    "http://www.informatix.co.uk/headers/"
is it implementing the extension properly?  Suppose it did a case sensitive 
string comparison with
    "http://WWW.INFORMATIX.CO.UK/headers/"
instead.  Would this be a correct implementation too?

My reading of your second rule is that the web server is the application 
"consuming" the name, and that it must "at a minimum use case-sensitive 
comparison", so the answer to both these questions is "yes".

Now suppose a web browser generates headers in these two forms when sending 
a request to the server.  Are they both correct implementations?

My reading of your first rule is that the web browser is the application 
generating the name, and it is not attempting associate different semantics 
with the two forms (it wants an MD5 checksum in both cases).  So the 
answer, again, is "yes" to both cases.

But now we have two "correct" implementations which do not interoperate, so 
I don't think this can be what you intended.

Maybe what you intended is that a web server _must_ apply the applicable 
scheme specific normalisations before comparison when searching for 
extension headers.  This means that a server cannot be written to process 
extension headers identified by a URI from a scheme it doesn't know 
about.  That's might be acceptable for web servers, but...

...how does XSLT (actually XPath) compare two names?  It can't apply scheme 
specific normalisations, because it may encounter names in namespaces with 
NSURIs from schemes which didn't exist when the XPath REC was published.
--
Cheers,
John

Received on Thursday, 20 July 2000 05:29:52 UTC