Re: Divide the problem

Julian Reschke wrote:
> 
> Dan Connolly wrote:
> > > I think that one of the reasons why this dicussiosn takes so long and
> > > progresses so slowly is that several issues have been thrown
> > together. Maybe
> > > we should focus on properly defining them, and to then discuss them
> > > separately.
> > >
> > > #1 is the original question about how to handle relative URI refs in a
> > > namespace name.
> > >
> > > #2 produces the most heat here: What is the namespace name? Is it really
> > > just a name which happens to follow the URI ref syntax (a), or
> > should it be
> > > treated as an URI [+fragment id] (b).
> > >
> > > (a) is what the official W3C recommendation says.
> >
> > Please cite evidence of this claim. I find it to
> > be entirely false:
> >
> > "[Definition:] An XML namespace is a collection of names, identified by
> > a URI reference
> > [RFC2396],"
> >
> > "[Definition:] The attribute's value, a URI reference, is the namespace
> > name identifying
> > the namespace. "
> >
> > http://www.w3.org/TR/1999/REC-xml-names-19990114/
> 
> I think it's worth discussing this. Basically the question is what
> "...identified by..." actually means. I don't agree that the REC says that
> the namespace actually *is* the resource behind the URI ref.

I agree that it's odd/awkward/confusing to say that a URI reference
identifies something... as specified, a URI reference denotes
an absolute URI (and possibly a fragment identifier), and that
absolute URI is what identifies a resource:

"A URI reference may be absolute or relative,
   and may have additional information attached in the form of a
   fragment identifier.  However, "the URI" that results from such a
   reference includes only the absolute URI after the fragment
   identifier (if any) is removed and after any relative URI is resolved
   to its absolute form."
	-- http://www.ietf.org/rfc/rfc2396.txt

> What it says is
> that you can take the URI ref to *identify* the namespace, that's it.

If I understand you (and if I take the liberty of
assuming you meant URI in stead of URI ref just there),
you're saying that
	some URI i identifies a namespace N
does not imply that
	the resource identified by i is N

To me, those are just different ways of saying the same thing.
How can one be true while the other is not?

Or have I misunderstood you?

> > > (b) seems to be what TBL
> > > and some others would prefer. Even *if* one would go for (b), I
> > claim that
> > > you still wouldn't be able to put something at the specified
> > location, until
> > > there exists a W3C recommendation which actually defines what to expect
> > > there.
> >
> > Interesting claim. I see no justification.
> 
> If you do not specify what to expect there, what is an application supposed
> to do with the document in this location?

Any number of things, depending on the namespace and the application...
Conventions can be layered on top of the namespaces spec; no
one set of expectations need apply to all namespaces (aside from
the built-in convention around URIs that you can (often) dereference
them to find some representation of the state of the resource).

For example, some namespace names are expected to be used with
RDF schemas, and they work with software that consumes RDF; other
namespace designers may choose XML Schema as the mechanism to
publish definitive information about their namespace, and
software like XSV works with those. If you point XSV to
a document whose namespaces are defined (only) using RDF, XSV doesn't
find any XML Schemas, and it'll report that the RDF-based
document isn't xml-schema-valid.

For almost all namespace names, it's really handy if developers
in debug-mode can fetch *something* about the namespace,
be it prose, or XML Schemas, or whatever.

If you want to use the same namespace name with RDF Schemas
and XML Schemas, life gets a little more complicated,
but you can use schemaLocation or content negotiation
to get your job done.


> > > Specifically, the new approach of putting XML Schema files at
> > > locations specified by W3C namespace names should be immediately stopped
> > > until there is a consensus about this.
> >
> > Again, why not? It works, and it's useful.
> 
> I suppose that with "it works" you mean that there are test implementations
> of XML schema which actually use it. Nobody is argueing with this. The issue
> is: is this the best way to achieve this goal? The namespace REC says that
> it is not the goal of the namespace name to point to a schema document.

It's not a goal of the namespaces spec. That doesn't mean that it's
not a goal of specs layered on top of the namespaces spec.

> The
> XML schema spec itself defines an alternate mechanism to achieve the  same
> result.

a similar result, that is. using schemaLocation involves cluttering
instances with xml-schema-specific markup; it's not compatible with
the usage I expect to be typical:

           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
              <head>
                <title>A Math Example</title>
              </head>
              <body>
                <p>The following is MathML markup:</p>
                <math xmlns="http://www.w3.org/1998/Math/MathML">
                  <apply> <log/>
                    <logbase>
                      <cn> 3 </cn>
                    </logbase>
                    <ci> x </ci>
                  </apply>
                </math>
              </body>
            </html>

	-- http://www.w3.org/TR/xhtml1/#docconf

> However, starting to put things "behind" namespace URIs on W3C's own web
> site certainly smells like the attempt to make something a fait accompli
> while the discussion whether this is the right thing to do still continues.

Isn't trying it out a good way to see if there are problems?

The discussion of whether a self-describing web can work
or not has gone on for years without solid/persuasive evidence
on one side or the other. Tim and I (among others) think it can work
and will be revolutionary. And yes, we're using our
position of leadership (i.e. our write access to
the W3C web site) to convince as many as we can.
This is our job. It's our stated responsibility to
"lead the Web to its full potential."

If Tim had waited until everybody agreed that the Web would work
before setting up the first web server and releasing the
first clients, we would have no Web.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 8 June 2000 10:01:08 UTC