Re: XLink: behavior must go!
John E Simpson wrote >Would it be fair to say that the behavior attribute of an XLinking element is intended to function as a sort of localized (element-context-specific) PI -- a trigger to XLink-smart processors that is ignorable by others? If so, in what way is such an attribute more problematic than actual PIs? The key point about the behaviour attribute is that it is instance specific, rather than element-context-specific. (You can deal with all element-context-specific problems in the stylesheet; it is instance specific changes that are the difficult ones to control without passing some form of control parameter.) Oren Ben-Kiki wrote: >If you can define a set of behaviors and make a good case that this set is applicable to the vast mojority of XML applications, they I'll gladly join you in lobbying for adding an 'xml:behavior' attribute to XLink with this set of values. In fact, I'm all for releasing XLink without a behavior attribute and creating a WG (or maybe placing it within the XLink WG mandate, whetever) dedicated to this attribute. I do not believe that we are yet in a position to predefine the behaviours. These must be specified by particular industry groups, not by W3C. I am not convinced that the behaviours needed for the US Defense industry will be the same ones needed by the European healthcare industry (in fact I know they are different). Why should I seek to impose the requirements of one of these groups on the other? What is needed is a standard "point of reference" that people can know where to go for information. Suggestions like <MYLINK ... BEHAVIOR="popup()"> (made by Paul Prescod) are not what I had in mind - behaviour should not point to a procedure it should either pass parameters that can be used by procedures, e.g <MYLINK ... BEHAVIOR="popup"> or better still, like namespace declarations, point to the source of the definition of the behaviour, e.g. <MYLOCATOR... BEHAVIOR="http://www.healthcare.org/xml/behaviours/popup_menu.xsl">. Note that the name of the parameter entity used to define behaviour is remote-resources-semantics.att - its the semantics we should be passing, not the calls. Note also the subtle change to the last example. Behaviour belongs on the locator rather than the link set. For simple links these are the same thing but for extended links this is not true. The key point is that for multiheaded links behaviour is controlled at link instance level. It is for multiheaded links that you need to control the behaviour of different members of the link set in different ways. Now to come to another point Ben made in response to my comments that: >It should not be necessary to have individual >stylesheets for individual instances of messages. >It should not be necessary >to redefine processes for each DTD that uses the shared information. Ben said: >Agreed; why do these follow from what Paul (and I) propose? I don't think they follow from what you have been saying, but they are something that has not been adequately thought through in the overall model of the XML family. Ben rightly suggested that we should used DTD fragments to define shareable resources. But how do you link sharable DTD fragments to sharable stylesheet fragments? How do you link stylesheets to local processes in a way that allow the local processes to be used with many different stylesheets, whenever a particular DTD fragment is invoked, and how do you provide user control over processes that are handled in multiple places. Remember that a multiheaded link is likely to be pointing to resources based on different servers, using different local processes to undertake business-related procedures that necessarily must be handled outside the stylesheet. I had said: >We need >to import standardized modules that will process standardized namespaces of >elements in ways that depend on the conditions applying at the point at >which the located data is to be retrieved from. Ben responded: >The 'behavior' attribute as it is specified - or should I say, unspecified - today, does not give you this power. As long as it doesn't have a set of well-defined valid values, it is wores then useless. I agree it is under-specified. I think it is too early (by 3-5 years rather than Ben's estimate of 1 year) to specify a decent set of acceptable procedures. I think the best we can do at present is to take the approach namespaces did - point to a resource that describes what is required and depend on the system having its own rules for resolving what that means. 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