Re: Anchors Aweigh
>>I don't think so. In many ways, defining links as objects is a good
>>way to start, because then you can work back to the representation
>>required at the protocol and definition ends of the system.
>Actually, this seems a terrible way to start (or finish). Object models are
>fundamentally oriented to the definition of _behaviours_. I am firmly
>committed to the notion that we should think of links as delcarative
>information about relations between documents and document portions.
I agree that we should be focusing on definition, rather than
behavioral aspects. I disagree that object models must fundamentally
be oriented toward behaviour. At the simplest level, an object is just
data and a set of methods for manipulating it. The simplest method set
is simply a get/set group of methods for accessing and setting
properties of the object.
That said, the reason why I think it might be good to start thinking
about object models is that it is a good way of clarifying what people
want from links (ie. clarify the semantics that people attach to
links, and then derive the required data members). We can then
use to move back to the actual target of our WG: definition
I never said I saw a set of IDL interfaces as being a the desired
output from this WG, and ideed, even quired whether it was in our
charter to do anything about semantic definition.
>We will probably require operational semantics for some techniques of
>locating document portions, but we should not assume that there is
>any single _right_ thing to do with a link and its endpoints, once
Right, but there is nothing wrong with having some simple object
definiton which shows what properties the object is to contain.
>I would be tempted to put link behavior into our XML style sheets,
>but maybe a separate link style sheet will work better.
This is the model I advocate strongly, as some people on this WG are
quite aware (Len, Martin, and Steve to name a few).
>In any case we should not conflate the presentation and interaction
>aspects of linking with the declarative, and "semantic relationship"
>aspect of linking.
Absolutely. I would prefer us to define a set of data which comprises
a link, and leave interpretation to the application.
>>>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.
>>Sure, this is a good *starting* point.
>For an interaction and linking style language: not for a link-definition
I think we are violent agreement, but have a slightly different angle
All the things you outline above, are things that I most certainly
agree with. My point is simply that unless we know what the objects
are that we wish to define, it seems quite difficult to define
them. The process of actually modelling links as objects, would give
us a set of object definitions that would be *trivial* to convert
between definition languages. I lergely do not care whether we define
the objects in SGML, XML, PASCAL, C, IDL, LISP, or whatever. Once we
have the object definitions, the rest is just syntax. The only
advantage in using IDL, or something link it, is that we could also
define some of the common semantics that people associate with a link
(eg. link traversal). As I said though, ultimately, this would lead to
us modelling the entire Web, which is not something I particularly
want to do, though it is certainly a possible future.