Re: URLs/MIME only? [was Anchors Aweigh]

Terry Allen wrote:
> 
> Len Bullard writes:
> | 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.

Yes.  If we propose to use independent links because we
see a clear need for them, how do we best express that 
using URLs?

> 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.

Correct.  
 
>  XML is specifically intended for use on the Web.

Assumption of project; may not be intent of users.
I hate to limit a market like that.  Don't get me wrong, 
I understand this assumption, but I feel other types 
of hypermedia will emerge for which XML will be 
useful.  The target is still the Web.

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

We need control of our markup back.  We need 
independent links.   We can define 
forms for declaring links so we can interoperate with 
them (objects or XML element types). I agree we do 
not need to redefine URLs, URNs, URIs, etc.

Precluding the use of other protocols isn't necessary.
Consider someone may want to use XML documents in 
stateful protocols.  All the address field has to 
know is which protocol is needed.  Right?

The whole area of generic identifiers and 
attribute sets for ilinks and clinks is up for grabs.
We can enumerate a set of candidates from existing apps, 
or we can define a way for any one of these candidates 
to be identified by type in XML markup.  It may 
be the case that all that is common is the URL in XML 
and as you say, context is the key.  The application 
knows it is an anchor because of <a.  Beyond that, 
it's URL linking just as HTML and VRML both recognize 
their own anchor types and do not need to understand 
the anchor types of other applications.  

What the author has to have in advance are the tokens that 
identify target application functionality.  To wit, 
I have to know, a priori, to specify a #viewpoint 
string to open a VRML world at a specific viewpoint.
What an XML app should do is let me specify that 
the same way I would in HTML or VRML so the 
concept of authoring it isn't alien.

*  Do we settle on a prudent list of 
   types an XML engine recognizes?  

*  Do we adopt an existing definition 
   of links?

*  Do we create property sets?

Nothing about XML prevents XML application builders 
from sharing tag libraries for the convenience 
of authoring.  Registry concepts are applicable.
If the consortium decides (this is consortium stuff), 
they can support the registry of interoperable hyperlink 
element types.  So where it can be <a, it is.

>  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?

URLs.  Absolutely.

Why URNs now?  

HTTP headers, yes.  

MIME?  I don't like using file extensions to identify types 
when archiving.  Call me old fashioned, but 
when the markup goes to cold storage, I want 
it to have as much information about the original 
system that it was built for as possible.
However, this is library work.  I don't think the 
network cares.

len

Received on Sunday, 29 December 1996 00:48:50 UTC