Re: http://www.w3.org/2000/02/xmldsig and broken links

The behavior of dereferencing our namespaces will now change. This isn't
critical, but for those interested ... Below is a message I sent to someone
who encountered a problem with the earlier behavior.

Forwarded Text ----

You've unfortunately encountered a problem that results from an attempted
hack on browser bugs. The behavior you encountered results from a symlink
that links the namespace to an actual specification. The fragment
identifiers even work; when you dereference:
         http://www.w3.org/2000/02/xmldsig#Object
 you actually see:
         http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/#Object
 but the URI in the browser is still show as:
         http://www.w3.org/2000/02/xmldsig#Object
 If you then browse the rest of the specification, and click on 
         http://www.w3.org/2000/02/xmldsig/signature-example-rsa.xml
 that file doesn't exist as you rightfully point out, and it shouldn't
really. It isn't my intent to provide another URL for the specification, but
good content for a dereferenceable namespace. The symlink is the hack that
has some bad side affects; the true problem arises when one tries the
alternative below that should work, but doesn't because of browser bugs.
 
 It'd be nice to have the server do a redirect. So when you enter
         http://www.w3.org/2000/02/xmldsig#Object
 you actually see (both in content and a rewritten URL in the address bar)
         http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/#Object
 However, most browsers behave inconsistently with respect to fragment
identifiers in redirects. My version of NS drops it all together; IE drops
the fragment from the address bar but goes to the appropriate section of the
document. Bert Bos document these problems in:
         http://www.ics.uci.edu/pub/ietf/http/draft-bos-http-redirect-00.txt
 
 I originally decided to err on the side of the symlink 'hack' that is
inelegant, hard to maintain (mucking with the file system to obtain http
service effects), and has the problem you encountered. I've now moved to the
HTTP redirect approach, which does the right thing, clearly demonstrates the
bug, but results in the user not being taken to the relevant portion of the
document in some cases.
 
 At 09:18 AM 5/30/00 -0400, Hugo Haas wrote:
 >
  >The following information has been sent 
  >from http://cgi.w3.org/cgi-bin/FAQNotice.pl available from the FAQ
  >webreq, please investigate
  >
  >
  >----------------------------------------------------------------
  >Originating URL:             http://www.w3.org/2000/02/xmldsig#sec-Schema
  >Comments:                    This is meant to be a stable, well-known URL
that lives forever and is explicitly referred to by the xmldsig spec (and,
probably, by every XML digital signature that uses a DTD), so it would
probably be good if it existed, and maybe even had exactly the right
contents.  I think what's going on is that /2000/02/xmldsig gets mapped to
the current version of the xmldsig spec, i.e.
/TR/2000/WD-xmldsig-core-20000510 at present.  My guess is that the mapping
should actually include a whole group of URLs in the subtree under
/2000/02/, but it looks as if right now only that single URL
/2000/02/xmldsig is  getting mapped. 
End Forwarded Text ----

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 30 May 2000 13:38:04 UTC