> > > Browsers that did not understand this new URL scheme say "browser:" would
> > > refuse to follow the links.
No, they would simply default to the standard 'goto' behavior. I have
explained this at least three times here (probably in different threads).
> I'm not totally fond of mailto: URLs, but mailto: and telnet: URLs
> fit the model of "addresses to do something via a well-known
> network protocol."
Not exactly. There is no guarantee that the mailto: or telnet: facility
is using SMTP or TELNET protocols, so your 'model' is a bit of a stretch.
Technically the telnet: facility should be called a terminal: facility...
In fact the activity which these URLs invoke is about 99% local anyway,
they clearly imply that a specific browser functionality is to be called.
The fact that it directs some communication to an external location is
irrelevant. You seem to be saying that something "should" be a URL if
it has any need to contain a network address, and "not" if it does not.
I continue to point out, people are looking up functions on the network
today, with a variety of distributed-scripting mechanisms. Regardless
of how you feel about accomodating their oddball mechanisms, you must
feel worse about accomodating their proprietary tags... ? If this can
be done in a stylesheet that's fine.
> I'm not opposed to having URLs as two attributes: the use of URN on
> tags fits this (today we can't use URNs but some day...).
To actually specify a function, you'd need to have names for the function,
for each argument to the function, and a known place for the result to be
returned. There is a need for more than one URN in this structure, as
each argument, and (in my opinion) the function itself need to be looked up.
> I don't think you've made a clear case as to what the heirarchical
> "something" you are defining with linkas: is or if why we need it.
I think I have made this case several times. It's a function-name space.
It includes internal, browser-implemented functions, proprietary functions
unique to a browser/document pair that are aware of them (as SCO's are now),
and external, network-distributed functions, as are supported by HotJava and
a likely flood of imitators. As to why we might need more than flat namespace:
Look at commercial C++ libraries. These are expected to interact with only
a few other libraries, usually of the end users' design, but yet vendors all
prefix the names of their functions with some distinctive name, e.g.
ZZ_name_which_might_conflict (). In this case there is no need to say where
to retrieve the library since you've obviously got it, and are compiling with
it. But expand this issue to a network with 30 vendors each inventing their
own function names, and no way to know which of the 30 def'ns of "footnote"
is in use... I admit that this does not look like an issue today. But there
is a very clear capability vacuum, and a clear need to distribute functions
that are neither hardwired into the browser, nor live solely on one server.
Every hypertext system I've ever seen, ended up inventing link types and an
extensibility mechanism so that the authors could invent their own. The HTML
world will be no exception. We have already acknowledged the clear need for
them to do so, if only to ensure that reasonable 'maps' can be generated.
> However, if we need it, I don't think we should use URL syntax
> for this heirarchy unless we can give a useful intepretation
> of what it might mean to use linkas: in one of the contexts
> where URLs are now used, i.e. on or
No. NOT EVERY *RESOURCE* IS A *DESTINATION*. Your argument is analogous
to saying "I don't think we should let the function name be a CNAME, unless
we can give a useful interpretation of what it might mean to use that name as
an argument to the default function". A URI is a data type, not a parameter.
You are confused because you most often see a URI as a parameter specifying the
destination of a default function (i.e. standard 'goto (HREF)' link behavior).
However, even in HTML now we have URIs specifying CGI-bin scripts, and other
forms of browser behavior (e.g. mailto:), as I have pointed out several times.
>Using a dotted list of names works for a simple heirarchy.
A simple hierarchy is acceptable for the near term. We aren't likely to
get 'versions' of link types for a while yet, and if we do we just call
them 'SCOnav2/...' or something.
> There was one post that suggested we might need to get some
> information on link information from a remote location, but I
> don't see this as a reason to define a "linkas:" URL any more
> than style sheets are a reason to define a "style:" URL.
Style sheets are a reasonable place to locate the lookup information.
As long as it is clear that the behavior of a given 'relationship' is
defined in a stylesheet, and defaults to 'goto (HREF)' if it is not
(next, previous, etc,. can be supported if they are accepted as standards).
> (I also don't see what the distinction is you are trying to make between
> "goto" and cgi scripts. )
With URIs in parentheses: 'goto (HREF)' vs. '(CGI-SCRIPT) [argument block]'
Doesn't it strike you as odd that we use URIs only for arguments with regard
to links, but only for the function name with regard to scripts ?
> and why. You talk as if what you were saying was generally understood
> or obvious: it's not.
I think it *is* obvious.
> I don't think we should use URL syntax unless there is a reasonably
> good fit with other ways URLs are used.
URL syntax is there to locate a RESOURCE (not a "destination") on the
network. It is used now for names of scripts that are localized on one
server. It is used now to specify specific browser functions to invoke.
There is no reason why it cannot appear in a stylesheet to guide the
browser to a definition of a particular relationship. URLs of this
form would not be expected to 'work' as an HREF, because they are *not*
an *HREF*. They are URLs. You are confusing argument names, and data
Craig Hubley Business that runs on knowledge
Craig Hubley & Associates needs software that runs on the net
mailto:[log in to unmask] 416-778-6136 416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5