Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
