RE: XSL Requirements (was: Microsoft extensions to XSL)
See below. -----Original Message----- From: Oren Ben-Kiki [SMTP:oren@xxxxxxxxxxxxx] Sent: Sunday, November 15, 1998 6:12 AM To: xsl-list@xxxxxxxxxxxxxxxx Subject: XSL Requirements (was: Microsoft extensions to XSL) Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote: >I think this might be the point at which we could sit back and take a look >(again?) at the requirements document. I say this because I assume the >requirements are agreed to (more or less) by the consortium's membership and, >consequently, form the scope and intent of the specification. I hope the >process has enough integrity that the requirements are a valid discussion >locus. The intent and scope of XSL are missing from the requirements document. In the XSL draft itself we have: "XSL is a language for expressing stylesheets. It consists of two parts: 1.a language for transforming XML documents, and 2.an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary." IMVHO mixing the two intents in a single standard is a mistake. There's a real need for a language which targets just the first part - the interest in XML demonstrates and drives this need. The second need can obviously benefit from a transformation language, but is really a separate concern. It isn't different in principle from needing an XML vocubality for specifying mathematical formulas, 2D or 3D graphics, invoice data, or any other subject matter. >It seems to me that a lot of what is going back and forth here might >either disappear or be improved in quality and relevance if we communicated in >terms of the requirements. Right. I think we have a basic disagreement between people who use merely the first part of the intent - XSL as a transformational language - and people who also care about the other part, the formatting semantics. [edN] I wonder how much of this split will still exist in 6 + months when the browser bowsers manage to get something working with respect to XML and CSS, XSL, and even DSL? (I've mentioned the InDelv alpha/beta code before as and example of alternatives -- pretty good support for basic formatting objects a la current draft, not so strong but still respectable on the template/select side.) The first group would like a transformational language which is strong enough to convert XML into whatever target language they need. Being accessible to the end user is a minor concern. [edN] We've just seen some posts pointing to all sorts of alternatives for doing this. If the argument is that it should be done client side as opposed to server side, I wonder if this is realistic at this point in the evolution of things? The second group would like a flexible style sheet language for HTML graphic designers. Being accessible to such designers is a major concern. [edN] I wonder how much of this pent-up and frustrated demand can be placed at the doorstep of the rather half-hearted, inconsistent and downright buggy implementations of CSS that we have to contend with? <snip> [edN] There are probably other constituencies as well: new technical opportunities attract new users/requirements although I don't think the amount or degree of change fostered by XML/XSL etc. will be as great as what has happened with the advent of HTTP/HTML. One comment which I found interesting (from Paul Prescod, I think) related to what XSL activity really is technical innovation rather than standard setting. He feels the effort is doomed to failure. If he is right, the practical, cynical side of me tends to agree...another side says, "I hope not." Perhaps the question is, "Who would you rather have doing your innovation for you? An entity trying to live up to rather more altruistic goals such as consistency and standardization? Or and entity that is trying to carve up some other entity under the aegis of, to me, rather questionable business model notions of market share and maintenance? To my mind what has been happening over the past 5 + years with respect to HTML and the 'browser guys' has been pretty adolescent. At the end of the day, who among them can say there has been any gain? There certainly seem to have been losers and that's us who have to try make it all work together. Is there any chance of splitting the XSL draft into two - say, XTL (eXtendible Transformational Language) and XFL (eXtendible Formatting Language)? <snip> [edN] In effect, this has been done (if not formally announced), I think. There was some back and forth a month or so ago about focusing on the transformation side in the short term (whatever that means) and leaving the formatting side to later in the process. Realistically, what tools exist do this and not much of anything else -- XP/XT, Koala XSL I wonder if the division isn't rather neatly captured already? On the one hand, in the notion of the template matching and relatively straight forward output mechanism, i.e., new tag names, additional text, process-children, etc.; on the other, with the 'fo' mechanism, i.e., display space management, graphics, text formatting, etc. Are you suggesting that there should be two separate and free standing specs? Maybe I'm already corrupted but I like the notion of being able to select, change/re-order, and show content all in the same place. What I'm not so convinced is necessary is the ability to run a bunch of procedural code as well -- this was the thrust of my initial response to the thread. Looking at the XSL requirements document (which admittedly looks a little neglected at the moment), the notion of where and when to use scripting is pretty clearly articulated. My feeling is that the DOM and intermediate tools like the SAXON libraries and even programmable servers, e.g., Jetty from Mort Bay Consulting, are a better locale for complex processing requirements; certainly for the first go-round of the standard. Divide & Conquer :-) [edN] Yup. I just want to make sure that battle is waged by the hands of the right folks. ...edN XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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