W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: URLs/MIME only?

From: David G. Durand <dgd@cs.bu.edu>
Date: Sat, 28 Dec 1996 22:00:43 -0500
Message-Id: <v02130507aeeb872634a8@[165.90.139.114]>
To: w3c-sgml-wg@www10.w3.org
At 4:40 PM 12/28/96, Terry Allen wrote:
>So *purely* as a point for discussion, let me pose the
>following:
>
> The Web uses URLs (and to some degree, nascent URNs)
> for link addressing.  Linking methods are expressed
> mostly within URLs, and URL schemes are not necessarily
> tied to the data formats of the target entities.

   I would go along with the HyTime crowd and restate this as "Web
_locations_ are defined in terms of URLs." There is only one link semantics
(document replacement), perhaps two, if we consider frames and targets
semantic (though I imagine that in XML all this could be handled, and
better, in style sheets).

   In trying to convince the distributed authoring people that document
versions should be explicitly encoded in the URL, I was informed repeatedly
that URLs are opaque, and that it's evil to interpret their contents, and
certainly no more semantics should be added to URL formats.

> XML is specifically intended for use on the Web.

> Why should XML specify any mechanisms for hyperlinking
> other than those already in use?

I assume you mean location, not linking (in keeping with the pedantry at
the beginning of the message). We need some other kinds of location:

   1. Addressing of parts of single resources.
   2. Addressing into document that do not have anchor tags at the places
we want to address.
   3. Creation of single documents that may span more than one URL.

   The goal is not to replace the URL, as to be able to supplement it with
additional structural information to make more precise linking possible.

   I suppose we could declare a format for "#" strings that encodes our
location ladder. In fact, doing so would solve a serious user-interface
problem for prospective browsers -- but I am not so sure that new magic URL
hackery is really very nice. There is something in this proposal, I think,
but it doesn't feel right to me yet. For instance
   link="#foo"
      would refer to an ID "foo" in the current document.
   link="#(TEI ROOT CHILD (4 CHAP))"
      would refer to the fourth chapter of the current document (but of
course as a URL, it should really be:
   link="#(TEI%20ROOT%20CHILD%20(4%20CHAP))"

   In the foregoing I am using ( to indicate an "extended address, with a
token for the type of address (TEI would proably be augmented by at least
some HyTime addressing modes).

   This would work as a relative URL, as long as the base URL is taken as
the URL of the main entity of the document, and not the entity it happens
to reside in. The syntax is ugly for the common IDREF case, but if we are
to allow queries at all this will not work anyhow, so it's not much of an
objection.

What do others think? I started to disagree, but I'm more ambivalent now...

> How are XML agents to interoperate with other Web agents if
> they do not confine their expression of linking semantics to
> URLs (maybe plus URNs), HTTP headers (generated from metadata?),
> and MIME types?

I think that we will have all of these available -- but they don't give you
very much, and I'd rather this group were defining markup, than making HTTP
or URL scheme extension proposals.

I still wish we were using HTTP headers instead of Processing Instructions
(the one SGML feature I have never even contemplated using).

   -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Saturday, 28 December 1996 21:54:14 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:03:50 EDT