W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: Anchors Aweigh

From: len bullard <cbullard@hiwaay.net>
Date: Fri, 27 Dec 1996 11:02:22 -0600
Message-ID: <32C4011E.10D8@hiwaay.net>
To: Gavin Nicol <gtn@ebt.com>
CC: bosak@atlantic-83.Eng.Sun.COM, w3c-sgml-wg@www10.w3.org
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 
desktop?

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.

len
Received on Friday, 27 December 1996 12:58:16 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:03:50 EDT