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
> 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=".