- From: len bullard <cbullard@hiwaay.net>
- Date: Fri, 27 Dec 1996 11:02:22 -0600
- 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 UTC