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