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
> So *purely* as a point for discussion, let me pose the
> 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.
> 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
* 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?
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