Re: Anchors Aweigh

Gavin Nicol wrote:
> 
> >>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.  I disagree that object models are fundamentally oriented 
to behaviors.  But if one starts there, behaviors are easy to describe 
or add.  Really, it is a different angle on this discussion.   There are 
a number of good object-oriented programmers here who can help 
move the hyperlinking discussion along by stating clearly from their 
point of craft what is needed to support XML hyperlinks.  That is, 
in the data declaration of a hyperlink, what minimal pieces of 
information are there and are always there for any class of hyperlinks.

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

Right.

> 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
> specifications.

Right.
 
> 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.

I will be interested to see if we can avoid it forever.
A <a href= has a behavior (goto).  A target= is behavior (get/put).
No stylesheet is involved.  An <embed is a behavior, etc.
Agreed these are a particular application's behavior, but 
they are the common things done with links and what any 
Web user will expect to do with XML links.

So, will XML app designers have to agree on a common set 
of tags they scan for?  Attributes that infer forms?  What?
How does the XML designer go about adding links to any 
XML document type assured that the framework can use it 
via the XML handler?
 
> >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
> >located.

I understand.  I repeat, the designers will be in there 
looking for <a (goto) <embed (spawn) <script (gosub) etc.
Those may not be precise, but approximately what is wanted.
Isn't it convenient to make it possible for each XML app 
designer to use the same behaviors?

> 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).

Which?  Behavior in stylesheet or separate link stylesheet?

Is the issue of link behavior in stylesheets, or links defined 
in stylesheets, the crux of the difference of approach by
David and the Hytime approach?  Jon Bosak mentioned to me in Seattle 
that some were coming to this project of the opinion that links 
should be defined in the stylesheet.  If this is a proposal, it
should be out on the table to be explored and contrasted 
with other proposals such as those from the HyTime supporters.
That indicates that we CAN'T discuss hyperlinking separate 
from stylesheets.
 
> >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.

As do I.  Again, implied behavior is already there in HTML.
How do we avoid it?
 
> >>>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
> >language.

Sounds good, but so far, how many existing applications work like that?
  
This is an implementation implication and I think we 
should stop and look at this very carefully.  An implied behavior 
in markup makes it easy to send an instance with no stylesheet.
 
> 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. 

It is another way to look at the problem. 

> I largely 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).

Consider the case where the object has everything it needs to handle 
the XML document type and no separate stylesheet language is needed.
Is that a valid application of XML?

len

Received on Saturday, 28 December 1996 00:21:15 UTC