the questions remains [was Re: Begging the Question

[james anderson <james.anderson@attglobal.net>]

My concern with the namespace recommendation is not its scope. My
concern is its "coherence". That is, I am concerned that aspects of the
specification are incongruent with other specifications upon which it
depends. Confusion about the "meaning" of the namespace URI is symptomatic.

This problem arises because, while the section cited by Mr. Gudgin below
states quite clearly that "it is not a goal" that the URI's entail a
retrieval sematics, many examples in the specification employs http URLs.

This problem could be rectified. It could have been, and well still
could be. Yet the parties with authority to undertake such matters
dismiss all objections to the content of the specification as
misconstruing. This perplexed me when the recommendation appeared two
years ago. It continues to perplex me now.

Why do the examples choose to use, as namespace identifiers, URIs which,
according to the referenced rfc2396, are members of "the subset of URI
that identify resources via a representation of their primary access
mechanism." In particular, "http" URLs?

Where the reader attempts to understand what an URI, or an URL, or an
URN is, they may discover that, for example, the discussion of the
syntax of a "common internet scheme syntax" for uniform resource
locators in rfc1738 - a syntax to which "http" URLs conform - includes
discussion such as that on the "url-path" component, whereby "the rest
of the locator consists of data specific to the scheme, and is known as
the "url-path". It supplies the  details of how the specified resource
can be accessed. ..."

rfc2396 itself goes on to suggest that the respective "URI scheme
defines the namespace of the URI, and thus may further restrict the
syntax and semantics of identifiers using that scheme". It reiterates
this notion where it discusses the "Scheme Component" and suggests that
"the URI syntax consists of a sequence of components separated by
reserved characters, with the first component defining the semantics for
the remainder of the URI string."

[It's their language, not mine.]

Where the chosen URI scheme is "http", the reader might reasonably
expect that the semantics described in the specification of the http URL
scheme should apply. That is, as noted in section 3.2.2 of rfc2068, "the
'http' scheme is used to locate network resources via the HTTP
protocol." That is, the intended use of this specific URI form is to
retrieve a resource. Where the uninitiated reader is left to fill in the
blanks, a reasonable supposition is that the resource might well be a
schema. Even though this stands in contrast to the namespace
recommendation's stated goals. Where the reader attempts to resolve this
quandry by asking, "well, if it's not a schema, then what is it?" the
situation deteriorates from bad to worse. This is not a happy situation,
but what's a reader to do?

The reader expects either that the namespace recommendation would
acknowledge that the consequences of retrieval are at present not
understood and therefore formulate examples to employ URI's which were
not associated with a retrieval semantics, or that the namespace
recommendation would describe the nature and use of the resource which
is to be retrieved from locations for which a URL is specified, or, at
least, that the namespace recommendation would say that the conformance
of a document which incorporates URI's with a retrieval semantics is
defined only in the context of an additional spec which does describe
those retrieval semantics.

The namespace recommendation adopts the semantics of URI's with respect
to authorities in pursuit of the goal of ensuring uniqueness and
persistence, but then ignores the retrieval semantics of the URL's which
it uses to illustrate its concepts. This is incoherent. It leads to
situations like the following

Lisa Rein wrote:
> 
> Greetings Uche:
> ...
> However, I probably gat asked that question from throughly puzzled
> students more than anything else when I was teaching:  "Where does the
> the namespace URI go to?" (Um. Nowhere.  I just looks like a URI.  It
> isn't one.)
> Why doesn't it go anywhere?  Could it go somewhere?  (No.  It could say
> "ooga booga" and it would still work.)
> Have I ever thought about maybe having it go somewhere?......(You get
> the message)
> 

Wouldn't it be easier to fix this? Issue a correction to
REC-xml-names-19990114  in which the examples use only URI forms which
entails only the minimal semantics which the recommendation can explain.
If the implications of a specific URI form are not understood, then
don't choose to use that URI form which will lead to questions which are
unanswerable. Why is it better to repeatedly respond to the confusion
which otherwise inevitably ensues?

Martin Gudgin wrote:
> 
> > > Most of the unfulfilling argument surrounding it springs from the
> > > assumption that, since namespace names *look* like URLs, they should
> *act*
> > > like URLs -- that is, that one should be able to to point a Web Browser
> > > at them and retrieve something useful since they look like something one
> > > might point a Web Browser at.  This assumption, while not unreasonable,
> > > is explicitly disclaimed by the namespaces spec.
> >
> > Really?  Where?
> 
> Section 2[1] says:
> 
> 'The namespace name, to serve its intended purpose, should have the
> characteristics of uniqueness and persistence. It is not a goal that it be
> directly usable for retrieval of a schema (if any exists).'
> 
> I note from this that it only mentions retrieval of schemata but maybe it is
> reasonable to extend the meaning of the statement to cover all resource
> types.
> 
> Whether this is the 'explicit disclaimer' that Jonathan meant only he can
> confirm or deny.
> 
> Martin Gudgin
> DevelopMentor
> 
> [1] http://www.w3.org/TR/REC-xml-names/#ns-decl