Re: clink/ilink direction (Was: anchor awareness)

Jon Bosak wrote:
> If I were an implementor I would say that this is handwaving.  Given
> the depths of difficulty we have glimpsed during this discussion, I
> don't think it will be very convincing to say that finding ilinks is
> not our problem.  It seems to me that finding ilinks is exactly our
> problem.
> Jon

That's easy.  It's a file.  A collection.

XML apps define food for applets.  How 
do we identify to the handler that an 
ilink is needed?  Conventionally, we 
have pointed at them with clinks.  
Unconventionally we have pointed 
backwards from the ilink into the 
document, a la an inverse index.
Text that is anchored (still 
directional but into text not out),
by the ilink does not know that it 
is linked.  If it is a control, 
it knows that.   This way, as 
many ilinks as we need can point 
to the same object.  

Is an ilink a:

o  syntactic device of XML?

o  a general form any language uses similar to  
required virtual interfaces?

We can't well define linking for the system 
without considering behavioral scripting.
We are in the SGML-narcicissm  of data declaration.
That limits our view, perhaps.  To enable 
XML to easily work with scripts, we have to 
plan for that when we work on hyperlinking.
One problem for us is to find a way to 
have script nodes that are easy for the 
XML engine to handle, and still maintain 
a data declaration approach.

VRML uses a fairly neat technique.
Like XML, it's just a node language
of types.  To create behavioral relationships, 
they declare route statements. They look like this:

ROUTE TimerTalos.fraction_changed TO TalosOrbit.set_fraction

#   send the eventOut timer click to eventIn motion interpolator

ROUTE TalosOrbit.value_changed TO TalosSystem.set_rotation

#   Send the motion interpolator event out to the event in
#   of the Space (vrml transforms coordinate systems of 
#   objects)

The nice thing about this, it's easy to understand.
Works like a patchbay of timer, motion color, etc 
engines.   It is easy to hook scripts because they 
are just another routed object of exposed events.

Route to well-defined interfaces of events and properties.
Easy to understand and also, minimal syntax!

I bring it up because it is essentially an independent 
link other than not being addressable.  I offer this 
example as an alternative kind of thinking on the problem 
of creating a scripted hub for XML multimedia.