It is a little clearer what you are talking about now. To explain
my confusion I'd suggest that there are several meanings of the
word "function" etc. in various contexts. It sounds like you are
talking about something in the vein of an object-oriented programming
language.
> > 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 <A HREF="..."> or <LINK HREF="..." >
>
> 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).
I'm not saying that URLs are destinations, you are. It doesn't seem
to me, however, that this heirarchy of browser functions has any
thing in common with other URLs.
If it's purely an abstract space of function defintions according
to various authorities, it seems like treating it like CLASS and
defining a different space makes sense.
If the function defintions are stored out on the network, we can
reference them with an ordinary URL with a protocol scheme like http://
or ftp://
The idea of looking at HTTP methods combined with HTML tags as a "standard"
"default function" may be a reasonable abstraction, but there are enough
different ways to interpret it, that it's not obvious to me.
I remain skeptical about the URL-like notation, but beyond that, it might
help to step back and spell out more details.
Is this purely a space of "function" names? Or would we offer
some abstract model of what these "functions" are allowed to have
as inputs, outputs or side-effects?
It seems like defining things well enough to make browser
functions interchangible between browsers is a lot like defining
a programming language or at least an API for calling an object
file format. This is potentially a "big" project. (To say nothing
of raising issues of "safe" scripting, tojan horses and whatnot.)
(If we defined an abstract heirarchy without enough defintion to
allow software interchange, it seems likely that the more functions
were defined, the smaller the proportion would be likely to be implemented
in any one browser.)
The original project of defining some "core" link relationships and/or
browser behavior could be a lot "smaller" in scope.
--
Albert Lunde Albert-Lunde@nwu.edu