- From: Mark D. Anderson <mda@discerning.com>
- Date: Wed, 22 Dec 1999 09:41:50 -0800
- To: <xml-dev@ic.ac.uk>, <www-xml-linking-comments@w3.org>
(sent to both www-xml-linking-comments@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
Received on Wednesday, 22 December 1999 12:47:46 UTC