[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink: behavior must go!
Martin Bryan <mtbryan@s...> wrote: >I wrote: > >>If you can define a set of behaviors and make a good case that this set is >applicable to the vast majority 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. That's also my position. >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">. We are agreed on that as well. The question is, what is the best way to ensure this? We have several alternatives: 1. Leave 'behavior' unspecified and rely on people's common sense. 2. Make it a requirement that values to 'behavior' must be URIs. 3. Use XML namespace mechanism instead to qualify the attribute name, instead of its values. The spec now uses option (1), which I think is unsatisfactory. Let us at least have an editorial note recommending URI values! Paul (I presume) and myself would rather have option (3), as being more in tune with other XML standards (namespaces). But (2) also gets the job done. Given that (2) requires a very minor change to the spec as it stands (just adding a sentence or two), I guess it is the most practical one. If that's what it takes to get the spec out the door, so be it. >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. Urr... My first name is 'Oren' and the last one is 'Ben-Kiki'. 'Ben' is sort of a prefix (son-of) in Hebrew, but is a seperate word. Never fails to confuse English speakers used to middle names :-) Anyway, I 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. Good questions! If I knew the answers, I'd probably be a W3C WG member instead of an outside kibitzer :-) BTW, I agree that these questions weren't thought completely through; however the WGs did invest time and effort in these directions - wo do have namespaces, for example. I would be happy if there was a WG which was dedicated to this issue, even if its output would be only a list of "recommended practices" explaining how exactly to use existing XML standards to achieve this effect. Since you've asked, I do have some notions as to how the above could be done. First, I think that some of these questions aren't quite the right ones. By this I mean that DTDs or XSchemas or whatever should be restricted to defining the structure of a valid XML document. Viewed this way it sharing DTD/XSchema fragments shouldn't be too hard. "All" you'd need to say is "and this element is as defined in the following DTD". Trivial issues such as namespace management are left as an excersize to the reader :-) Assuming this issue is resolved, there remains the question of how to share stylesheet fragments. Given that this is a completely separate issue, XSL already provides ways to do this. "All" you need to do is provide a "library module" stylesheets containing the templates for some functionality - transforming certain elements in certain ways. The ability to specify template modes and names is invaluable here; it ensures that these "modules" won't be invoked unless you explicitly activate them. Note that nothing stops you from providing a DTD/XSchema "fragment" and an associated XSL one, if you insist on tight coupling between the two. But you can also provide multiple XSL fragments for the same DTD/XSchema one, for separate styling/transformation goals. You could also provide XSL fragments which were applicable for a wide range of DTDs - consider for example the IE5 XSL stylesheet for viewing arbitrary XML documents. In short, I strongly feel that the assumption that a DTD "has" a stylesheet is wrong. As long as it is being considered, this issue will get nowhere. BTW, all this relies heavily on the XML namespace mechanism and the use of URIs, and otherwise builds on existing XML standard. However, these standards haven't been fully adjusted to namespaces yet. For example, there's at least one potential problem in XSL - AFAIK mode and template names can't be URIs, they must be simple names. I'll raise this issue in the XSL mailing list. A WG dedicated to this issue could go through all XML standards to ensure they match these scheme, and could make a better case for changing a particular standard if necessary. Another issue you mentioned is user control over this process. I think this ultimately falls in the domain of application designers. Almost by definition, end users will _not_ write CSS stylesheets or (shudder) XSLT stylesheets. They will expect to be able to select from a menu of predefined presentation options. It is an interesting question where these predefined options can be defined in an "application independent" manner. That's the only option which would guarantee users a freedom of presentation formats. However, as long as the W3C promotes the "single conversion" document processing model: "arbitrary data" + "stylesheet" -> "presentation format", there will be no application independent stylesheets. If you want them, there's no way around "arbitrary data" + "application dependent transformation" -> "universal semantics", then + "application independent stylesheet" -> "presentation format". The trick is defining the "universal semantics" language, of course. Currently the only candidate is HTML, and since it is a horrible universal semantics language you can't really write application independent stylesheets for it. It might be too late for the W3C to start developing such a language, anyway - not that they are even trying. Barring someone else doing it, there will be no application independent stylesheets. A pity, really. Share & Enjoy, Oren Ben-Kiki 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
|