Re: Anchors Aweigh

David G. Durand wrote:
> 
>    I am one of the object programmers on this list. One of the problems I
> see with this is that I want to know what the data is, not how someone else
> thinks they should design my applications. 

The object of the quest is to see if this is a way to define 
what any XML system should be able to handle vis a vis 
hyperlinks.  The point was to avoid the Spy Vs Spy arguments 
of definitions by grounding it in a programming approach 
most of us understand and none of us own or have deep 
feelings about. 

> I would be more snaguine about
> OO modelling of links if I had ever:
>    A. Seen an object model for hypertext that more than the author agreed
> was reasonable.

The VRML community did it over a summer.  In less than a year, the 
apps were out and being used.  It can be done.  We have the 
somewhat more difficult problem of a markup approach as 
opposed to a purely "these ARE the objects" node set.

>    B. saw any proposed, meaningful applications of inheritance in defining
> the semantics of the two kinds of links we are considering (multi-end
> clink, multi-end ilink).

Then they are non-instantiable.  Abstract classes.

>    C. any reason to apply the operational aspects (methods) of OO
> programming. We don't even need "set" methods in XML, so I don't see that
> OO field lists, with "get" methods only, are any different from simple
> lists of attributes.

That is the idea I think would be useful to kick around if only 
to eliminate it from consideration.  Eventually, we have to 
work with scripting so, defined interfaces to an abstract 
XML document type might be one way around the problem of lots 
and lots of XML document types, each with it's own, as 
David Megginson pointed out, "badly written parser".
 
>    We don't need to sprinkle OO magic dust over declarative linking to make
> XML fly, we just need to decide on a syntax, and some simple metadata. (I
> think this is Gavin's model, and I'm not surprised that if this is so, we
> are in agreement again...)

You could be right.  This is an avenue to define something we could 
all count on working moreorless the same way every time, as well 
as establish a basis for a shared class of XML operations and 
data definitions.  VRML made this approach work very well because 
it cuts away a lot of academic haggling and gets to an 
implementation in short fashion.  That is why 
I can write play the current VRML 2.0 worlds complete with 
behaviors on any two browsers.  I don't claim they all work 
perfectly, just that they work.  If they worked perfectly, 
I'd consider that magic.

you see, what I would really like is the HyTime contingent 
to explain how the Hytime terms, properties, groves, grove 
plans, etc. work in an object framework.  I know it can 
be done with TEI, IADS, IDE/AS, DynaText, MIL-PRF-87269, 
the Philly DTD, MIL-PRF-28001 and every other DTD to 
which an element type for a link has ever been added.
These systems don't interoperate.   HTML and VRML do 
and they aren't even in the same syntax, but they agree 
on what a hyperlink is and does down to "target=".

len

Received on Saturday, 28 December 1996 18:58:55 UTC