This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3121 - extra / in namespace document
Summary: extra / in namespace document
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xpath-functions/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-18 14:10 UTC by Dan Connolly
Modified: 2006-06-13 15:08 UTC (History)
0 users

See Also:


Attachments

Description Dan Connolly 2006-04-18 14:10:53 UTC
xquery F&O gives http://www.w3.org/2005/xpath-functions as a namespace, but when I go there, I get redirected to http://www.w3.org/2005/xpath-functions/
where it says... Each function and operator is uniquely identified with a URI of the form: http://www.w3.org/2005/xpath-functions/#name

What is the full URI of fn:starts-with ?
Comment 1 Norman Walsh 2006-04-18 16:23:34 UTC
The specification is clear, I believe, the full URI for fn:starts-with is http://www.w3.org/2005/xpath-functions#starts-with
Comment 2 Ashok Malhotra 2006-05-19 13:06:04 UTC
Norm will fix when preparing next round of publication.
Comment 3 Norman Walsh 2006-05-19 13:17:03 UTC
But I want it left open until it's fixed :-)
Comment 4 Norman Walsh 2006-06-06 15:18:14 UTC
This will be fixed in the 8 June publication round.
Comment 5 Norman Walsh 2006-06-12 19:36:16 UTC
We failed to fix this because of constraints in the web server configuration
Comment 6 Norman Walsh 2006-06-12 19:38:34 UTC
Proposed solution: rename the collation URI to /2006/xpath-collations/codepoint
Comment 7 Michael Kay 2006-06-12 20:32:55 UTC
I don't think I see the logic why changing the collation URI should have any bearing on this problem.

And please could we not change the collation URI at this stage without very strong justification. Any change will be very disruptive.
Comment 8 Norman Walsh 2006-06-12 20:48:34 UTC
It's an ugly practical detail in web server administration. I thought changing the collation URI would be less painful than changing the xpath-functions URI :-)

If you do a GET onthe xpath-functions namespace, you want "/2006/xpath-functions" to appear in the browser. (Because people are going to cut-and-paste it and "/2006/xpath-functions/" is a different URI for namespace purposes.)

But if a directory named /2006/xpath-functions exists, a request for /2006/xpath-functions is always redirected to /2006/xpath-functions/

And because we have another URI named /xpath-functions/collations/..., we can't remove the xpath-functions directory.

Rock. Hard place. Between. :-(
Comment 9 David Carlisle 2006-06-12 22:32:46 UTC
And because we have another URI named /xpath-functions/collations/..., we can't
remove the xpath-functions directory.


Norm, cant you remove the directory (so trailing slashes dont get added) but still keep the URI /xpath-functions/collations/ by silently rewriting URLs of that form it to serve files from somewhere else?

David
Comment 10 Norman Walsh 2006-06-13 11:16:32 UTC
I don't think silent rewriting will work, though it might. Henry Thompson also suggested to me yesterday that using ScriptAlias and just taking over the entire tree might do it. I'm experimenting. With luck, this issue will silently close itself again today :-)
Comment 11 Norman Walsh 2006-06-13 11:50:35 UTC
Indeed, David, you're right. RewriteRules will do the trick. I'll get webreq to install them and then close this again. Whew!