W3C home > Mailing lists > Public > site-comments@w3.org > October 2002

Re: Re-broken links (was Re: Namespace redirections: (Was: Some broken links on http://www.w3.org/2000/09/xmldsig]))

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 25 Oct 2002 15:27:55 -0400
To: Clément Séveillac <clem@via.ecp.fr>
Cc: site-comments@w3.org, webreq@w3.org
Message-Id: <200210251527.55164.reagle@w3.org>

On Friday 25 October 2002 02:39 pm, Clément Séveillac wrote:
> I am afraid the links are broken again: on
> http://www.w3.org/2000/09/xmldsig#sec-Schema, all the links:
>
> http://www.w3.org/2000/09/xmldsig-core-schema.xsd
> http://www.w3.org/2000/09/xmldsig-core-schema.dtd
> http://www.w3.org/2000/09/xmldsig-datamodel-20000112.gif
> http://www.w3.org/2000/09/signature-example.xml
> http://www.w3.org/2000/09/signature-example-rsa.xml
> http://www.w3.org/2000/09/signature-example-dsa.xml

Clément, these URLs were never "published" (you won't find them in the 
spec), instead what happens was that when you typed in the namespace 
'http://www.w3.org/2000/09/xmldsig#' we served the specification in its 
stead (without changing the URL in your address bar) and you encountered 
them from subsequent browsing. What we did to fix this was to make sure 
that when you typed in the namespace URL in the future you dereference the 
specification *and* the URL in your address bar also changes to reflect 
that: 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ '. 
Consequently, relative URLs from that will work as they should for 
subsequent browsing!

Of course, there are other issues. For the URIs that are published within 
the specification, such as 'http://www.w3.org/2000/09/xmldsig#X509Data'
when you dereference that you should get:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html#sec-X509Data 
.
Unfortunately, most browsers will screw this up. Either when they see the 
redirect from our server (to the spec) they forget the fragment identifier 
(so you won't be taken to the right section of the specification) or they 
sent the wrong accept headers (NS/Mozilla) in the request which confuses 
the content negotation. (Browsers should ask for 'text/html' or 
'application/xhtml+xml' and will get the specification; XML applications 
(e.g., schema apps) can ask for 'text/xml' and 'application/xml' and will 
get the schema.)

If all of this is more than you care about, sorry for the confusion and if 
you want to browse the specification, please use the URL found in the "this 
version" found at the top of the specification.
Received on Friday, 25 October 2002 15:28:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 16:21:27 GMT