Re: [httpRange-14] empiricism was Re: resources and URIs

Dan Connolly wrote:

> >
> > I understand this position, you are saying that all HTTP URIs identify
> > *documents*, that is to say all resources which are directly 'on the
web'
> > and who are identified by HTTP URIs are documents.
> >
> > How do I reconcile this position with the empirical evidence that some
URIs
> > identify resources whose representations claim that they are XML
Namespaces?
> > I just can't reconcile this by accepting that an 'XML Namespace' is a
type
> > of 'document'.
>
> Why not? It's a little awkward, but as you point out, emperically,
> the conclusion follows.
>
> e.g. in the SVG case, when you visit that URI, you're looking
> at a representation of a document; it says
>   "This is an XML namespace defined in ..."
>

The conclusion only follows if we accept the premise that all HTTP URIs
identify documents.

In the SVG case, when I visit the namespace URI, I am looking at a
representation of the namespace, which is the namespace document. Why am I
necessarily looking at a _representation_ of a document?

Indeed when I browse to http://www.w3.org/2000/svg# I am looking at the same
thing on my screen, but you would agree that this URIref need not identify a
document? Same for an example: http://example.org/foo#person -- with Accept:
text/html -- I might be looking at a description of a person in my browser,
but you agree that this URIref might identify _a person_ not a document
about a person.
...
>
> This is closely connected, in my mind to the Qname->URI mapping issue
>  http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6
>
> My favorite solution to that issue is: to compute a URI from
> a namespace name n and a localname l:
>   if n.endsWith("#"): uri = n + l
>   else: uri = n + '#' + l

agreed.

>
> But there are more details to fill in for namespaces like XML Schema
> that have lots of kinds of local names. My preference is: if you
> have a clash, that's too bad. Don't use the same name for two different
> top-level constructs.
>

considering URIrefs for XML Schema particles makes my brain hurt.

>
> >  Do you believe the
> > Web Architecture ought be documented based on its empirical existence or
> > based on a grander design?
>
> Hmm... I kinda think the existence is grander than the design.
> But I think Web Architecture ought to be based on both.
>
> Case in point: do you think the HTML 4 spec, published
> in 1997, should have encouraged the use of the <font> tag?
> After all, emperically, that was the most straightforward
> way to get font changes onto PC screens. But there was
> a design, present in the code all the way back to 1990,
> for using stylesheets. That design is now reasonably
> widely deployed, and I think the Web is better for it.
>

Agreed. Wholeheartedly. That was intended partially as a reponse to Tim
Bray, who stated in an earlier message that the intention of WebArch was to
document the Web as it currently exists i.e. based on empirical evidence. I
am giving empirical evidence for one side of the [httpRange-14] POV. In
terms of Grand Design, I've heard two different positions, one that URIs
might identify anything, and another that HTTP URIs necessarily identify
documents (or perhaps information resources -- if these get defined). It
seems that both positions are supported by empirical evidence, and unless it
is decided to let both coexist, one or the other would need to get
deprecated.

I've been told that "SW" arguments ought not come into play here. I've no
problem reformulating these arguments in terms of the traditional web + XML,
which is why I brought up the XML Namespace issue.

Jonathan **

** my view of the SW is that it ought be entirely compatible on the
traditional Web, indeed 'layered' on the traditional Web in some sense of
the term 'layered'.

Received on Monday, 21 July 2003 11:48:49 UTC