Re: Is XHTML a dead end?

Norm,

> | I definitely think that the selector aspects of HLink require more
> | work. To be really versatile, they need to be more along the lines of
> | XSLT patterns or CSS selectors. But doing that would have a *major*
> | impact on whether you could use XSLT (in the way that you demonstrated
> | in your email) to do it, since XSLT lacks functions for dynamically
> | evaluating XPaths or matching patterns.
>
> Right. The approach I outlined only works because HLink is described
> in terms of elements and attributes. If it switched to a CSS-like
> syntax, as has been discussed on xml-dev if not here, it would be
> much, much harder to address with XSLT.

I guess there are ways around it -- build some XSLT automatically
based on the HLink spec or something. Or there's always the
possibility of using extension functions.

Or (sigh), have the HLink processor annotate the Infoset with extra
linking properties, and build in some special functions in XSLT to get
hold of those.

|>> 3. I think the "onRequestSecondary" is dreadful. Surely there need to be
|>>    tertiary, etc. methods if there need to be secondary methods.
> |
> | This is why I keep wibbling about XML Events. To get real flexibility
> | so that users can precisely indicate what kind of "event" triggers a
> | particular link, you need something at the XML Events level. This
> | might be hideous, but perhaps HLink needs a bit of indirection --
> | something like having the actuate attribute take an IDREF that points
> | to a "behaviour specification" further down that describes, at an
> | event level, what activates the link. I dunno whether this even
> | *belongs* in HLink.
>
> Something like that might work, but it seems *awfully* complex. I'd
> be quite happy with a few fixed idioms (just a few more than are
> currently available) tied to specific elements and attributes.

Except that you want them to be *your* idioms rather than anyone
else's, right? ;) I dunno -- I was kinda thinking along the lines of
there being some fixed idioms, like onRequest and onLoad, that every
processor recognised, and then if it didn't recognise one of those
then it could try to hunt down a specification of what it should do,
or it could fall back on doing nothing. A bit like the way that XLink
does it now, with its 'other', except that instead of 'other', you'd
have a pointer to a spec of some kind.

I dunno -- I'm just exploring ideas here. But I think that if HLink is
something that's going to be pursued then getting the requirements
down and agreed on is going to be more useful than trying to think
about how to fulfil them.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 4 October 2002 07:00:41 UTC