Re: Link Behaviors

David G. Durand wrote:
> As far as I can tell, we need query functions, and the ability to specify a
> few behaviors:


>    Offer choice of options (menu or list as appropriate to display device)
>    transclude content

PickOne.  PickMany. (someone near MID group will remember why 
the Logo, "more meta than thou" was used). '=)

>    navigate, replacing current document,


>    navigate, creating a new display area (as appropriate to display device)

spawn - do it, then it is the framework's problem

>    Highlight linkend (since it may not be in the markup, this cannot be
> part of normal rendering)
>    Can anyone think of any other link behavior we need?

gosub - navigate, do what you do, return here

It is convenient to be able to specify a chain: an entry 
point which is fixed for sequences of instructions.  In 
MID, we used an element type and that may be best left 
as an application convention.
>> Proposals are needed.

>   And starting, I think.

Yes. Looking good.

> > To get the credibility needed for acceptance,
> >not only the spec, but appendices on implementation and/or working
> >code will be needed.
>    I have not seen any suggestion that is remotely problematic enough to
> necessitate this yet. It may happen, but not yet.

I keep it in mind because I haven't experienced a successful 
project of this type that didn't need it.  We tend to forget
that even with our individual differences, we know a lot 
we assume others know.  Having seen that error before, I've
learned the value of the point and click proof. 

API appendices make it explicit what is always 
expected of a language handler.  Given that XML is a 
metanotation, is this needed? An API is also a data 
declaration of function/message calls.  Is it the 
case that defining a standard XML handler is a 
separate effort from XML-the-language?  Is it the 
case that several groups may undertake this as a 
standards effort with the usual ensuing lack of