[
Lists Home |
Date Index |
Thread Index
]
> The description you provide is pretty accurate.
> http://example.com/page/part_in_a_page refers to a resource identified
> as http://example.com/page/part_in_a_page , while
> http://example.com/page#part_in_a_page refers to a fragment of the
> resource identified http://example.com/page.
Hmm, let me be clearer, "/page" is expected to resolve. Don't start on me about
URIs not being required to be resolvable. Humor me a bit. The thought being a
request for http://example.com/page is going to return "something" in the form
of a document, possibly an HTML file. So my thinking is that a request for
/page#part_in_a_page is going to be some section within the /page document that
is in one way or another identified by the 'part_in_a_page' string. I fully
realize how screwed up this is, especially if /page returns and XML document.
I'm naively saying that in such a case the fragment has "some sort" of ID tag
that matches up.
Yes, this does seem decidedly lame. Especially when there's a desire to use
versioning in there. Hold on, let me get my spear so I can go gore _that_
sacred cow for a while... My interest is simply in trying to find useful ways
to look at URIs as something more than just overly large opaque identifier
strings.
> >Is there a good/bad reason not to do it this way?
>
> As long as you're referring to resources and fragments inside resources,
> it makes great sense. How that should relate to QNames is a weirdly
> different problem - one where people appear to have confused string
> concatenation with URI processing.
I daresay you're entirely correct. I'd certainly appreciate some QName for
Dummies examples.
> That part appears to be unfixable, with the people who created URIs in
> general as well as with the people who created particular URIs.
Sadly so.
-Bill Kearney
|
