Re: XML Schema working with DTDs?

At 09:27 2000-04-29 -0500, Dan Connolly wrote:
 >> 1) In the nicest possible way, I'm not sure what we owe to Joseph on
 >> this one.  We have _not_ published this namespace yet, in the sense of
 >> asserting publicly in a process-blessed way that
 >> http://www.w3.org/1999/XMLSchema is the namespace URI for a namespace
 >> whose semantics are defined in some officially approved REC.

Looks like the conversation is not distinguishing between issues related to
(1) religion (which I care little for), (2) the pragmatic (which I
encourage) and (3) the difficult (which I sympathize with).

I don't think anyone can really technically argue against the position that
if the syntax or semantics identified by a dated namespace substantively
change, so should the namespace. It's a pain in the butt, time consuming,
and editors/WGs may not opt to do it, but let's not waste philosophical
arguments on that point. It's a matter of priority and setting a good
example, which editors might not opt to do.

Unfortunately, if it isn't done, it begs a whole slew of religious
arguments. Consequently, my pragmatic approach has been to (1) change the
namespace when there are substantive changes (would an instance that
validated before, validate now?) and (2) to make the namespace a URI that
redirects to the right spec. On the first point, the editors in xmldsig have
made mistakes with drafts going out with an odd example having an
inconsistent namespace, but we're hopefully getting the hang of it. (If we
were editing in XML it would just be an entity ... ) On the second point,
I'm sure that at some point I'll forget to update the symlink
'/2000/02/xmldsig#' and people might not dereference the latest spec. But,
given (1) it'll still be close enough. Also on the second point, I'm
beginning to think an actual URI rewrite (in an .htaccess) would be
preferable to a filesystem symlink, even if client drop it, but I'm still
mulling that over (and wonder if it can be fixed [1]).

I'm forwarding my proposal of how I dealt with this issue below.

BTW: Has there ever been any consideration in schema (I thought I saw this
but don't see it presently) to include a location attribute in the schema
element type? If a namespace need not be dereferencable (like PUBLIC) then
wouldn't it make sense to include a SYSTEM as well?

[1] http://www.engelschall.com/pw/apache/rewriteguide/#ToC18

__

Date: Thu, 24 Feb 2000 19:41:11 -0500
To: Dan Connolly <connolly@w3.org>, Tim Berners-Lee <timbl@w3.org>,
swick@w3.org
From: "Joseph M. Reagle Jr." <reagle@w3.org>
Subject: My experience with dereferencing namespace URIs in TRs.

Dan informed me that there is a W3C policy that namespaces must dereference.

I've implemented a technique
        http://www.w3.org/2000/02/xmldsig#
that I think meets the expressed requirements, but some observations:

1. I decided to use the "#" strategy instead of the "/" because (1) I would
like the dereferenced URI to yield content, it might as well point to the
appropriate part of the spec (Instead of setting up a slew of separate
resources, or a query parameter); (2) I seem to be in good company with RDF.
2. However, this requires use of a symlink as I understand clients drop the
'#fragment' when parsing a HTTP-301/302 Location header. (If this is an
apache problem, then we could just patch apache ...).

The result was that:
1. I had to ask Eric to patch his ACL script to work over the symlink.
2. The symlink was a relative one; Gerald expressed concern that symlinks in
general are less maintainable:
        ln -s ../../TR/2000/WD-xmldsig-core-20000228/Overview.html
xmldsig.html




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

Received on Saturday, 29 April 2000 20:20:02 UTC