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

Re: URLs/MIME only?

From: Terry Allen <tallen@fsc.fujitsu.com>
Date: Sun, 29 Dec 1996 09:17:45 -0800 (PST)
Message-Id: <199612291717.JAA16067@ishtar.fsc.fujitsu.com>
To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org
David Durand writes:
| 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).
  [ ...]
| > 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

???  Here's the "pedantry":

=== ===
Len Bullard writes:
| you see, what I would really like is the HyTime contingent
| to explain how the Hytime terms, properties, groves, grove
| plans, etc. work in an object framework.  I know it can
| be done with TEI, IADS, IDE/AS, DynaText, MIL-PRF-87269,
| the Philly DTD, MIL-PRF-28001 and every other DTD to
| which an element type for a link has ever been added.
| These systems don't interoperate.   HTML and VRML do
| and they aren't even in the same syntax, but they agree
| on what a hyperlink is and does down to "target=".

They do so because the behavior of the link is implied
by its context and because the addressing is completely
contained within the URL.  The commonality is in the
use of URLs.
 === end "pedantry" ===

I'm talking about linking to locations.  There's a URL scheme
proposed for linking by byte ranges.  There are URL schemes for
linking to parts of multipart MIME messages.  Still purely
for discussion:

| 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

Indeed, that syntax is already available.  Here's what the revised syntax 
draft, v00, says (after remarking that # is a delimiter and neither it 
nor what follows is part of the URL):

   When a URL reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URL by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URL, but is often used in conjunction with a URL.  The
   format and interpretation of fragment identifiers is dependent on the
   media type of the retrieved resource.            

So the point is that URLs give you a way to do this already, 
the fragment identifier mechanism is bound to be developed by
non-XMLlers, and as you show in the rest of your response (deleted),
it's not hard to do for pointers into XML documents.  What 
architectural advantage is there in the Web context for XML 
in developing alternate mechanisms that may not be interoperable?

    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html
Received on Sunday, 29 December 1996 12:19:15 EST

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