xlink, xinclude, show, and actuate

[Mark D. Anderson]

(sent to both www-xml-linking-comments at w3.org and xml-dev;
please follow up just to xml-dev.)

I just read the latest (dec 99) revs of xlink and xinclude, and have
some thoughts.

I think everyone agrees that the "show" and "actuate" attributes feel
uncomfortably like display-specific hacks. 

Paraphrasing, as currently drafted the show attribute is one of:
- "embed": stick it here
- "new": make a new window
- "replace": replace this window

I would maintain that "new" and "replace" are actually hiding complex
links. They imply a target which is different from the current
location: they specify that the identified resource should be
loaded to either a new child of the "all windows" collection,
or to replace the current window in that collection. Those are
different locations in the "GUI tree".

I would suggest that the "show" attribute should be broken down into
two separate attributes:
- "target": the location that the href resource should be loaded to,
if different from the current location. It could be a relative or
absolute url, in either case utilizing xpath.
- "operation": NMTOKEN, one of:
-- "insert", insert as new child of target
-- "replace", replace the target
-- perhaps others such as "merge", which would merge descendants with target

If the currently proposed "show" is retained, it should probably
be placed in a different html namespace, since it is display specific.
It is syntactic sugar for something like:
  html:show="embed" -> xlink:target="." xlink:operation="replace"
  html:show="new" -> xlink:target="//dom:windows" xlink:operation="insert"
  html:show="replace" -> xlink:target="ancestor::dom:window" xlink:operation="insert"
(Presumably the target could be expressed in a suitable mapping from DOM
to xpath, when/if that exists, in the html usage case.)

Note that the 4th case missing from the existing show attribute
is IMHO still useful: xlink:target="." xlink:operation="insert".
That corresponds to an inclusion case where I want to leave a "marker",
and not replace the element.

Now with respect to "actuate", which can currently be "onLoad" and "onRequest":
these two are very display specific. And while there are just two,
in fact a document might go through any number of layers/tiers of processing
(some on the "client" and some on the "server"), and it might be desired for
any one of them to be the one to actually act on the declared link. 

If the current actuate were to be preserved, I would suggest it
be moved to the html namespace. I might note that the two current
choices are far less than what the more ambitious dhtml sites are using
today in load timing (actuate 10 seconds after my stupid flash demo,
actuate with a fade, actuate when i roll over this gif, etc.).

Since the semantics of actuate has to do with timing, I would think
that some tie-in should be specified to SMIL or at least to DOM2.

Some of the important dimensions to consider with respect to activation:
- the id of the processor (or layer) that is examining the content
- the event(s) that should trigger an actuation
- the role of the link
- the type of the located resource

The actuate attribute could probably be done away with. 
An "activation-event" attribute might be added. Then the html group
could define things like:
  html:a -> activation-event="html:onRequest" 
  html:img -> activation-event="html:onLoad"

But I'm not real happy with that either. On the client side, I'd want
a tighter integration with the DOM events. On the server side, I have
no need of actuate at all -- the fully qualified role name should be
sufficient for me.

With respect to xinclude, at first I was pleased with the separation
from xlink, but now upon further reflection I believe it will lead
to a confusing and artificial separation of capabilities.

In my view, xinclude is just a case of the "actuate" being done
at an earlier stage than is currently allowed for in the simplistic
set of 2 choices in xlink actuate. xinclude has potential need for the
the "target" attribute described above, and perhaps for further
control over who should expand it.

For its part, xlink could benefit from the "parse" attribute that
xinclude has. Speaking of "parse", I think that both would benefit from an
even more powerful capability of indicating what processor
to use to load the resource (which might be implied by type),
as well as processor directives and/or a processor stylesheet url
(which might be done some how as a complex xlink?).
This could be used to provide something like architectural forms, for example.

I think the "steps" attribute should just be ditched. xslt seems
to be doing fine without a "steps" attribute to control how far
it should follow possibly infinite recursion in calling templates
or importing stylesheets. It is an implementation level issue.
After all, suppose that I want to allow an infinite number of steps.
Will the processor really do that?

There is still the pernicious confusion in xinclude about where
in layering it stands with respect to validation and the DTD, which I
sympathize with and have no good suggestions for at the moment, beyond
those mentioned in the spec. That could be an obstacle to the (re)unification
of xlink and xinclude.

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)