XLink: behavior must go!
Paul Prescod wrote: >I believe that the XLink behavioral attributes should be removed. Theoretically they mix presentation and structure. This causes all kinds of practical problems addressed below: Behaviour *must* stay. What we need is some mechanism for passing through behaviour control properties from the instance to the XSLT. The behaviour attribute provides us with a standardized point which we can query from within XSLT to determine which types of behaviour a particular instance of an object should have. In fact the behaviour attribute should move from the XLink to XML standard, as xml:behaviour-control, but that is is bit too radical for people to bite off just yet. In the meantime it is vital that at least XLink provides us with a standardized mechanism for controlling instance behaviour. (Paul is right to say this is really a "hints" thing -but it is something more than a hint - it is a set of parameters that can be used to control behaviour where appropriate.) >We could go whole hog and specify exactly what they look like (e.g. popup menus, buttons, hotlinks, etc.) and provide options for styling them. But that would further violate a major tenet of the XML religion: the separation of presentation and structure. No we could not! In the first place XSL is not defining a GUI. In the second we could not begin to guess what the *user* requires. What if the user is blind? None of your suggested behaviours would be of the least use. What if the behaviour said "convert this instances of of invoices to euros before display" or "use the current exchange rate to express any prices in the linked document in the user's local currency"? What if the behaviour said "If this instance of the message is selected do not allow the user to select another of the listed options"? You cannot predefine the behaviour of all (or any) XML document instances - you can only provide an extensible mechanism that people can use to indicate what type of behaviour may be required and what controls should be used for this purpose within the XSL processor. >Take all references to behavior and traversal out of the XLink spec. Move it all into a pair of specification called "Extensions to XSL for Link Rendering" and "Extensions to CSS for Link Rendering." Again its a question of who is in control. We need to leave authors with the right to make choices without having to be stylesheet designers. One type of behaviour I would like to see is to be able to control which stylesheet should be associated with a particular instance when traversed via a particular linked document. As it stands authors have no control over the presentational style of a non-embedded instance. (This is a great agrument for auto-embed as it allows the display of the recalled data to be controlled by the local stylesheet.) We need a better mechanism for choice of stylesheet than those currently being shown. For example, I would like to be able to select the stylesheet used based on the language setting of the user's locale. How can I do this? We desparately need mechanisms to manage both link behaviour and the behaviour of stylesheets associated with linked documents. One attribute to do this, rather than a whole set of customizable ones that change from environment to environment is the only way we are going to get transportable interactive documents. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format