Re: Anchors Aweigh
Gavin Nicol wrote:
> >What would really help this discussion more than
> >abstractions on linking would be set of IDLs for an XML handler.
> >Define the XML handler public services.
> Actually, this would be a *very* interesting approach to the
> problem. We could model the entire web in IDL. Great for compatibiliy
> (objects addressable as CORBA objects seems like a real win to me).
True, but there is also the Active X model. MS or no, it is clear
that a stripped down COM model has a lot to offer and has a lot of
support both in existing objects and in knowledgeable users.
What I would like to see from the object-designers on the list is a
rational comparison of XML hyperlinking goals and how these
fit inside Active-X or Corba, what is apples/oranges, etc. It
is likely I am conflating layers here.
Grounding the discussion of hyperlinking in implementation
proposals based on examples (eg., the IPB thing) would help
some of us out of the terminology quagmire. I am also one of
those who stumbled for years with HyTime terms until I realized
the directional issue was part of the problem. Like others,
I thought of the link as the control which pointed out to the
target (with any number of notation conventions from local
app name, file extension, magic number, etc.). In IDE/AS
for example, the linkend attribute is heavily loaded with
arguments for the target app as I noted previously. We
can sort these out and ask if XML defines the way such a
string should be built, but first, is this XML's charter?
I think it is.
> The problem with this approach is that you *will* model the entire web
> (ie. you'll have to model documents, protocols, etc. etc.) unless you
> wish for "undefined" behaviour to creep in.
Gack! Not the WHOLE thing! ;-)
What I was aiming at was the link semantics of the XML handler.
We more or less know what the current crop of desktops are doing
and we have listed those. We have a number of examples from
SGML systems and applications that desire web-capability.
From these we ought to be able to say what, from a requirements
point of view, current systems need to support initially.
Creeping undefined behavior doesn't bother me as long as
the defined behaviors are there and we can share the definitions
unambiguously. Information systems creep. I'm used to that.
> >For object oriented programmers to build what we say we want, we have
> >to tell them how much the XML spec defines the behavior of the system
> >that handles it? What services do we want from that .dll? What is
> >the XML handler interface to the framework?
> Yes. Once we start defining behaviour, there is no end to it until
> you've defined the application. I think a *very* important decision is
> whether we wish to head down that path or not.
I agree. Unfortunately, it is hard to define links without some
notion of behavior. In MID, we had to attach attributes with
values for gosub, goto, spawn, other. I never cared much for
"other", but the first three were clear enough. Of course, we
were dealing with a design in which an interoperable behavior
spec was a primary deliverable.
> As Len rightly notes, link resolution is a seperate problem to link
> specification. I believe that link resolution mechanism definition is
> not part of the charter for this group (unless I am quite wrong). If
> we start defining resolution mechnism behaviour/semantics, we'll end
> up reinventing the Internet.
> The beauty of a URL is it's opaqueness.
Agreed. I presume most of the list members are receiving the
uri.bunyip discussions of the revision of the URL specs.
I posted the VRML example so others could see what is done
with the term "anchor" in other specs including the operations
fields for tree operations. VRML carefully separates internal
behaviors and the sorts of things an external API does.
However, VRML is an application language, not a meta language.
So, I think it wise to be clear how far a behavioral spec goes
in XML, and how much advanced hyperlinking XML must define
vs what an application of XML defines. What must any three
applications of XML share operating within the same
BTW: I apologize for the weird spacing in that post.
Cutting and pasting from WordPad to NS2.01 mailer is
problematic. The new Nav4.0 mailer is much better.