XSL Debate, Leventhal responds to Stephen Deach
The following article was posted on the xsl-list and the newsgroup comp.text.xml. My apologies to those that read more than one of these lists. Although most of you are probably tired on the XSL debate by now I felt this would interest some on this list. Mr. Deach, chair of the XSL Working Group, issued a personal response to my article in xml.com "XSL Considered Harmful" in the xsl-list mailing list. I felt his thoughtful article merited a follow-up from me. My other responsibilities have prevented me from answering many other equally compelling articles, for which I beg your understanding. I think Mr. Deach has done a good job of bringing most of issues into sharp focus so I hope these comments will answer the questions of many others as to my views. I am happy to let anyone that wishes to follow up on this article have the last word as I have had ample opportunity to let my thoughts be known but if anyone is terribly keen to pursue any particular point further please cc my email address at michael@t.... I am at your service. The complete text of Mr. Deach's Response is quoted in sections in this article. > As a member of the XSL working group and having worked in the computer > industry for over 20 years on a broad spectrum of products to author, format, > and render communications vehicles of many kinds, (word processors; DTP > applications; commercial newspaper, magazine, directory, catalog, and > advertising production tools; slide show authoring; data base and document > management systems; web site authoring; photo image editing and retouching; > charting, illustration and engineering graphics; font creation and rendering; > and the internal software in typesetters and printers, etc.), some making > extensive use of structured content and stylesheets and some making little or no > use of stylesheets, I certainly qualify as an expert in document modeling, > content editing, styling, and formatting tools. I have seen debates of this > nature many times and prefer to ignore them, as they usually blow over. In this > case, due to the timing and the stridence of his statements, I feel it is > necessary to respond with my personal opinions on Mr. Leventhal's so-called > challenge. I further feel that it is necessary to respond because he makes a > series of claims (which I believe to be false) and then directs you to reach the > same conclusions and so vote. I appreciate the fact that my colleague, Mr. Deach, chair of the XSL Working Group, has taken the time to respond to my article and has taken considerable care in so doing. Perhaps it is appropriate to state something about my background as well. I have spent slightly little less time than Mr. Deach in the computer industry, about 16 years. One important difference in our experience is that the greater part of my career was not spent in the area of document-related tools and products. Among other things I spent many years working on software used in the design of integrated circuits and in magnetic resonance imaging. The last seven years of my career have been dedicated to electronic document software, touching on both structured and unstructured document technologies. I worked on a pre-Web SGML browser called Oracle Book, have been involved in the Web since its earliest days at CERN, and am currently working on my second browser, this one based on the mozilla open-source code. The reason I think my non-document related background is important is that it has always given me a different perspective on technologies like SGML and XML from that which is common to the vast majority of people working in this area. Most of my colleagues have traditionally had publishing-related backgrounds. I felt that SGML had the potential to fill a very critical niche as an information as opposed to document-related technology but simply had too much dross in it originating from the technical view of the publishing industry professionals that made the heaviest contribution to the development of the standard. I argued for a "purification" of SGML and at least some of my ideas had an influence on the creation of XML. I am still dissatisfied with XML as it still carries some of the dross from SGML but in this imperfect world it is something I can live with. I believe that at the core of the debate is the difference in view between those that see XML and the web primarily as an engine for traditional ideas about document publishing and a broader view not tied exclusively to publishing that sees XML as the primary interface layer to the multitude of ways in which we can use knowledge, computers, and networks. I should also mention again (it was already stated in the article) something about my experience with transformation. It did occur several times in the debate that noted advocates for XSL made the claim that I or anyone else that disagreed with their position did not understand XSL. Along similar lines some have said that my article was motivated by my economic interests. I have not responded to such statements since to the discerning reader they do more discredit to the person making them than they could ever do to me. But I do know and understand XSL as well as DSSSL as well as at least a dozen other approaches to transformation and have made my living as a professional in this area for several years, choosing the best and most efficient tool for the job without the least interest in ideological debates. I may add that I have received very strong support from my colleagues in this field who are today, as I was in the past, making their living from doing XML transformation. And my support for and preference for CSS goes back at least to 1997, long before I undertook my current project, as is evidenced by my article "XML and CSS", published in the W3C Journal in that year and reproduced in the very first issue of xml.com. Mr. Deach mentions the "timing and stridence" of my article. While I will always be extremely quick to apologize for rhetorical excess and any hint of impoliteness (difficult to avoid from time to time in this medium) I do think that the timing is appropriate and the stridence is proportionate with respect to the overall situation. I would like to share with you my view of "how the war began". I don't think you will find any stridence at all in my article "XML and CSS" or my book published last year, "Designing XML Internet Applications" (where I discuss both XSL and CSS) although I did not hesitate to express some doubts about XSL (or DSSSL) and to praise the simplicity and power of CSS. However, the situation begin to look very different in the last six to nine months when we saw Microsoft refusing to commit to correct support of CSS while introducing XML to web world in IE5 beta through XSL and conversion of XML to HTML on the client. I begin routinely encountering web users who had absolutely no idea that it was even possible to display XML without transformation to HTML - using, of course, Microsoft XSL. To make matters worse, what users were encountering was a proprietary implementation of XSL far in advance of even the Proposed Recommendation stage which would give it status as at least a probable future web standard that would be reliable in its broader outlines. In my view experts in the XML community were doing everything possible to encourage this state of affairs - there was quite nearly a "blackout" on the mention of alternatives to transformation and alternatives to formatting such as CSS. You can not find better proof of this than the fact that neither CSS nor the DOM is even mentioned as a "standards related to XML" on the SGML/XML on the Web Page. As I said to Robin Cover, the editor of the SGML/XML on the Web Page, this is a profound disservice to the newcomer to XML who has no indication that the simple stylesheet language he may already know from his use of HTML can be used to quickly display his XML in a web browser supporting current W3C standards. Instead he is directed to use a declarative transformation language which is still a W3C Working Draft to do a document-to-document transformation to a new presentation-oriented XML language for which no implementation in browsers currently exists. I realized what a disastrous situation had emerged, and to large measure been created by the XML community itself. The Microsoft browser supports XSL transformations and the Mozilla browser took the CSS route. The very raison-d'être of the W3C had been shot straight through the heart as it was not going to be possible to create one XML web page with one stylesheet and to see it correctly displayed in any browser. And all partisanship aside it was obvious who was right and who was wrong: CSS is a W3C Recommendation, XSL is not. I decided that I must speak out on this issue. I began posting to comp.text.xml but met mostly incomprehension from people coming over from the Microsoft XML list that were convinced that the only proper way to handle XML documents was to use Microsoft XSL to convert them to HTML and from the few XML folks that deigned to pay attention and only wanted to deflect the argument into a pointless debate about whether transformation programs were better written in XSL declarative syntax or in a procedural language. One person who finally did respond was Ken Holman after I confronted him on the stage at the Swedish XML/SGML User's conference with the statement that XSL advocates bore heavy responsibility for ensuring that we did not have a common stylesheet language for XML in browsers. Ken was unable to respond directly to my perfectly accurate assertion but reiterated that he thought that transformation was important and that XSL was the way to do it. He later wrote the article that appeared in xml.com where he attempted to diffuse the "perceived controversy" between XSL and CSS although without addressing the major points of the controversy. My article in xml.com was originally entitled "A Rebuttal" and was no more than attempt to present the an "other side" which heretofore had been suppressed by the XML community. But it was not actually when I read Ken's article that the "war" began, it was a bit earlier when I read Tim Bray and Jon Bosak's article in Scientific American where it was stated that XSL was "the" stylesheet language for XML. In demographic terms Scientific American readers are one of the most influential publication-defined communities on the planet. It was then that I said "This is war, it has to be a war." Finally, Mr. Deach says I make a series of claims which he believes to be false and goes on to, in his view, refute them. When I made my "declaration of war" I did make a strong and open challenge to XSL and thereby exposed myself and my ideas to, shall we say, extremely intense scrutiny by XSL advocates. Frankly, I am surprised that I did as well as I did, I think that in that an impartial judge would say that each of my major points essentially held. On many points there was essentially no debate whatsoever. For example: A programming or scripting language with the DOM provides a more powerful transformation capability than XSL-transformation. XSL-FO does not provide any clear advantages over CSS formatting and CSS is, in fact, a powerful formatting language for XML. XSL provides no solution to interactivity. These three points alone represent to me an enormous, "captured ground". The fact is that the whole situation is completely reversed from what it was before I launched my "war". The person looking into XML today is not going to hear that XSL is "the" stylesheet language for XML. No one is going to claim that CSS, which happens to be the current W3C Recommendation, is not a viable alternative to XSL, no XML consultant would dare not to mention CSS. No one can claim that there are no alternatives to XSL transformations or even that XSL transformations are indispensable. No one can ignore the fact any longer that vendors have not agreed on a single stylesheet standard for the Web. The large numbers of people that do not want a declarative transformation language, do not want to go through a document-to-document transformation to even see their XML documents, and do not want a supercharged FONT tag language to replace semantically-rich XML now understand that there are viable alternatives - that these things are not "the" XML story. Those that think XML should be useful in creating a real application environment in Web browsers are relieved to know that XSL is not "the" XML story. I have not enjoyed the "war", I would rather express myself in very cool code rather than write articles, but I think I have reason to be proud of these accomplishments. And on these points alone it is clear that the correct action for W3C members remains, clearly, to vote against an XSL Recommendation. As it currently stands this is very essential because XSL-FO must be dropped. XSL-FO is entirely redundant with CSS, restricts or eliminates interactivity, and encourages or even requires the elimination of semantic information from transformed Web documents. Even among those who staunchly defended XSL-transformations there was broad support for this position. The least that should be done is to separate XSL-FO and XSL-transformations into two entirely separate initiatives. I also advocate against approving a separate XSL-transformation Recommendation as XSL-transformation does not serve any of the purposes for which the W3C creates Recommendations. Recommendations are there for key infrastructure which must be interoperable. Multiple and redundant recommendations work against, not for, interoperability. A document-to-document transformation language like XSL has not been shown to be an interoperability requirement and in any case is redundant with already existing Recommendations. No one has successfully argued that the existing Recommendations are inadequate, let alone that they could not improved to add new capabilities. That said, there is no reason why work on XSL-transformation can not or should not continue outside of the W3C. An additional XML tool is always welcome as long as it does not compromise the interoperable environment of the Web. > I must at this point, for legal reasons, re-emphasize that these are my own > opinions and not necessarily those of the XSL-WG nor necessarily those of my > employer. > The timing of his challenge is inappropriate because XSL is still a working > draft, yet he claims XSL is deficient because: If the timing of the challenge is inappropriate it is clear that the timing of the debate is not. But the XSL community has accepted my point that other transformation methods are more powerful than XSL. No one has suggested that a later point in time XSL will be more powerful than can be imagined or realized today. > a) XSL is a future technology > Response: This is what a working draft is, by definition, a future > technology. Every technology goes through this phase. > > b) The specification is in flux and there is significant change from > draft to draft > Response: Keeping the public informed about the current state of the > W3C's efforts, making the rate of change and degree of change visible to the > public is exactly W3C's goal in requiring the publication of working > drafts. > > c) Only limited preliminary tools to use it exist > Response: but tools do exist and the users of these tools have > provided substantive feedback that has lead to improvements in XSL. > > d) Those tools are incomplete or don't implement the latest version > of the draft > Response: Again, exactly what one would expect as a specification > evolves. Yes, so I have said myself, and stated that responsible conduct by the XML community would have been to point new users and vendors at existing Recommendations. > The terms of the challenge are extremely vague, they can be tailored so that > both sides could declare victory. The outcome of a challenge whose 2 criteria > for measurement "better" and meaningful" is guaranteed to be indeterminate. Both > terms can only be measured "in the eye of the beholder". > A number of claims are made about the value of XSL on the web. Many of these > claims are either false or they completely miss the point. Well, ok. Let's see. > Claim 1 Interactivity is a requirement for a technology to be useful > on the web. > Response: This is completely false. The vast majority of web sites are > essentially static. Interactivity, beyond traversal/addressing and some level of > data-entry (form fill-in) has little value for a huge class of meaningful > sites/documents. I really can't see the connection between "completely false" and the explanation of why that might be so. I think I'll just stick to it, a transformation technology which does support interactivity and the browser environment pretty much has no role to play in a browser. As I put it, "in the evolution of web technology into the new desktop", close to an irrefutable statement. It may not be true that the vast majority of web sites are essentially static but certainly the fast majority of web pages are. But evolving web technology doesn't exist to create a web as it exists today. I think I provided a pretty good list of real interesting things that can be done with interactivity "beyond traversal/addressing and some level of data-entry" in my article. And I don't think the web community in general is going to share Mr. Deach blasé feeling about interactivity. > Claim 2 XSL precludes interactivity. > Response: No more so than CSS. Well, does Mr. Deach care about interactivity or not? It is DOM+CSS that I described as the combination that gives transformation and interactivity and styling. > Claim 3 Print has no place on the web. I said the Web is "not about paper documents" and the web was not the place to do page composition. Everyone likes to be able to print documents, that isn't the issue, it is whether you should expect to get FrameMaker+SGML documents out of a web browser or not using a page composition engine. > Response: This issue has been discussed extensively in the XML.com > mail forum and on the mulberrytech.com's xsl-list (public comment list for XSL). > The fundamental responses have been: > For a large number of people, print is important. The web is as much about > formerly paper-only documents and print-on-demand as it is about interactive > and animated ones. For which there are existing technologies, fortunately not inside the browser. > Paged composition is not significantly more computationally intensive than > browser formatting. Ridiculous. > Paged views (fit to the window and/or page) are extremely useful for some > content. For which ... existing technologies ... > Claims that the market for repurposing is a handful do not explain the > robust attendance in these sessions at Seybold Seminars and other conferences > for the past 3 years. Repurposing has nothing to do with whether a page composition engine should be inside a browser. > Though one could create separate stylesheets in CSS for viewers, XSL for > print-on-demand, PDF for critical print, etc. I don't want to if I'm not > forced to. The training cost and error rate is unacceptable. The vast majority of web users don't even want to create stylesheets, let alone declarative transformation programs like XSL. FINALLY, as Håkon Lie has pointed out, even if you want to do page composition in the browser XSL still does not do that for you. Transformation is far from enough. > Claim 4 XSL is a danger because it removes semantic meaning. > Response: XSL allows you to preserve the semantic meaning of your XML > by not polluting the XML with presentation (as happens in HTML and in HTML+CSS > today with semantic-free divs & spans and with the widespread misuse of the > remaining tags). What does HTML have to do with using XML and a stylesheet? FOs are a font tag language which remove the semantics from otherwise perfectly fine XML that could be displayed with CSS or transformed with the DOM and keep all the semantic information. That simple! > Claim 5 FOs are bad > Response: A related FUD issue to the claim that they remove semantic > meaning. This issue originated in a paper posted by Mr. Lie (and referenced by > Mr. Leventhal). You should also look at the archives of the mulberrytech.com's > xsl-list to evaluate the response to Mr. Lie's paper and e-mails. Many of his > key points were disputed or discredited. Our distinguished colleague and author of a very thoughtful and cautious paper is furthest thing from a dispenser of "FUD" that I can possibly think of. I combed through every single article in the Lie-Prescod FO debate and I came to conclusion that Mr. Lie's arguments were rock solid which is why I simply pointed to his paper rather than try to better his statement of the problem. There was a major sidetrack on HTML and divs which I found not at all relevant. > I refer you also to James Tauber's response to this issue: CSS tags ARE > formatting objects. The 'display' property identifies the fundamental formatting > behavior of the element, this is exactly what an XSL-FO does. I would add: > XSL-FOs are simply more general (cover a broader scope), and defined in a manner > that has fewer side-effects (interdependencies). If anything, CSS is the > "supercharged FONT tag", XSL at least compartmentalizes the side effects. Yes, I like this line of argument very much because I realized the reverse is even more true and it blows away your entire rationale for having an FO standard. Just improve CSS however you like and if someone wants an FO language they can make elements fo1 to fo653 and map each of them to a CSS style. Fortunately it is going to be really rare than anyone needs to do that and for the majority of users they will be introduced to simple CSS stylesheets that encourage them to think stylesheet and semantics rather than going into the whole business of transformation to another language. The FOs nearly guarantee word processor-like stylesheet abuse. Really, it often seems to me that you want to turn the Web browser into Microsoft Word! > Claim 6 XSL gives me nothing new > Response: There is a huge class of documents that are not made > available on the web, because either formatting/pagination is inadequate using > existing standards, or because they must be broken into little sub-documents for > presentation. XSL gives me a much more convenient and format-rich way to > transition this broad class of paper documents to the web. XSL also makes it > easier to build stylesheets for those documents that need to be authored for > both online and print media (including print-on-demand). We are back to the Print arguments, please see above. Nothing new in this nothing new section! > In this class of documents I would include: any document used in a business > transaction or legal context (including proposals, requirements documents, > contracts, court filings, insurance policies, tax documents, safety notices, > forms); any document used in a design or manufacturing context (design and > manufacturing specifications); any document used in a service, customer > relations or customer support context (various types of manuals, instructional > inserts); any document used in promotional context (catalogs, e-catalogs, > newsletters, brochures, and mailings); any document used in an educational > context (including textbooks); and the bastions of traditional print > (books/e-books, newspapers (?), magazines/e-zines). These documents are > meaningful because people either pay for them or pay to produce them. > Claim 7 I can do all the formatting you can by adding a few minor > tweaks to CSS > Response: Anyone who has built more than one or two formatters (and I > have built over a dozen) recognizes that to add proper pagination and layout to > CSS requires quite a bit more than a few tweaks. Again, see Print. Where should page composition be done and with what tools? XSL isn't enough. Let's have the whole story. On the other hand, simple pagination is a reasonable CSS goal. > Claim 8 Anything you can do in XSL, Mr. Leventhal claims he can do in > some combination of existing web standards: the DOM, CSS, and scripting > Response: One, not all the technologies referred to are web standards or W3C Two, at least. Right? And for the scripting, ECMAscript by reference and the language-specific binding in the DOM make the third at least debatable. > Recommendations. Two, this misses a key point. As a programmer, Mr. Leventhal > can do anything. But most users aren't programmers and vehemently don't want to > become one. XSL can be built into tools that the web designer or graphic artist > can use, that are predictable and implementable. Dealt with adequately and fairly in my paper. What is false is that XSL makes anything difficult any easier. Just about any serious transformation takes someone with the skills equivalent to some kind of programmer. Fortunately the vast majority of web documents will be very happy with a CSS stylesheet. It is XSL that sets the entry bar unreasonably high. And not only are we not going to see reasonable transformation scripting tools that for graphic artists but most people would rather you didn't hand them a language for which they must have such tools before they can do anything. > Claim 9 XSL didn't take into account anything learned from history (I > assume this means CSS) I don't know where this is from. My two favorite themes have been the history of the development of programming languages (declarative transformation languages have been tried and failed) or the history of the evolution of the web (stepwise refinement of the existing environment unless there is a truly compelling leap possible). The discussion which follows about XSL and CSS is not a point I have ever gone into. > Response: This is completely false. XSL had significant participation > from users and implementors of CSS as well as participation by a number of > members of the CSS WG, including the CSS&FP chair. In addition, the XSL WG > membership includes participants that worked on DSSSL and/or have experience in > building commercial formatting and authoring products that averages 10+ years > each. > XSL includes all the formatting capability of CSS and nearly all the CSS > properties (verbatim). It similarly includes much of the capability of DSSSL, in > a more approachable manner. > And no, XSL is not "DSSSL in sheep's clothing". The XSL submission and > charter require the XSL WG to support the functionality of both CSS & DSSSL. > Well over half the effort of the group defining the XSL formatting objects was > to understand the full capabilities, the property interactions, the > discrepancies, and the limitations of BOTH these formatting languages, then > redefine the formatting model in a compatible manner. XSL fully incorporates the > formatting capability of CSS. > DSSSL was a well-thought-out solution to most of the problems that they were > trying to solve. That problem differs from XSL's, hence DSSSL is not a > sufficient answer to the web formatting problem. > The same can be said of CSS, it is a good solution for the problem that it > was originally intended to solve. However, attempting to extend it to solve the > range of problems that XSL is intended to address will make it an ugly and > unimplementable language. A different architecture is required to support some > of the extensibility that XSL requires. > As with any solution there are things one didn't consider, mistakes that are > made, and features deferred to the next release. Because a solution isn't > perfect doesn't mean it isn't useful. (If that were true, we should ban HTML, > CSS, XML, XSL, SGML, & every other W3C, ISO, ECMA, IETF, etc. standard. None > are perfect.) But we have never had a complete implementation of CSS1, let alone CSS2. I wonder how much we can all really understand so we can build on this effectively? We had many years to think about the flaws of SGML before we created XML. We had an enormous test bed for each revision of HTML before the next came along. We have not gone up the learning curve with CSS. I hear claims like "DSSSL is not a sufficient answer to the web formatting problem", and a "different architecture [from CSS'] is needed to support some of the extensibility that XSL requires" without support for the assertions. I don't think either of these assertions are true. DSSSL does arbitrary transformation, period. What is wrong with DSSSL? What is meant with "different architecture" is usually simply the transformation capability. Which has been shown can be done in other ways, when and where it is needed. > Claim 10 XSL is in competition with CSS. > Response: Most of the developers of XSL consider the 2 complementary, > not competing. CSS provides a convenient and workable mechanism for those > documents to which it is suited. XSL extends the market to documents and styling > requirements that are not well addressed by CSS. The W3C has established a joint > committee to maintain compatibility between XSL's & CSS's formatting models > and properties. Well, let's see you get 100% beyond a full CSS1 and CSS2 implementations in browsers, let's see you second my (polite and appreciative) note of protest to the SGML/XML on the Web page about the omission of CSS as a related XML standard, let's see you amplify my warning about the fact that we do not have a single stylesheet standard for XML today and maybe, maybe, I will begin to lend some credence to your claim here. > Claim 11 XSL is hard > Response: Experience with the preliminary implementations of XSLT have > shown this to be untrue. For simple things, XSL is no harder than CSS. For some > of the more complex things (that one can't do in CSS alone, it does become more > difficult, but it is less difficult than learning the DOM and scripting for > someone who doesn't already know them or for someone who isn't a programmer. Stylesheets have been a part of the web for years as well as part of authoring tools for many more years. This is a somewhat familiar concept to the average computer literate person. It is preposterous to suggest that document-to-document transformation is as easy as a stylesheet. I have compared the difficulty of DOM and scripting compared to XSL on the basis of experience with declarative vs. procedural languages on the fact that programming languages support modular construction and other features to ease the writing of maintainable programs, and that virtually any programming language is will permit one to perform a plethora of common and essential tasks that are not supported in XSL. I haven't seen any refutation of these points. > Claim 12 Scripting is more powerful than a declarative language > Response: This is true, as far as it goes. It also forces everyone to > be a programmer. XSL is a declarative language, not because declarative > languages are easier to use or more powerful, it is because declarative > languages are more implementable and more reliable. Having had firsthand > experience with PostScript (a procedural language) and PDF (a declarative > language) prior to joining Adobe, one finds that one gets only moderate gains in > the ease of authoring in the declarative language and that the declarative > language does have some limitations in capability. The biggest gain in switching > to a declarative language is in predictability and reliability of the authored > input (it can be validated) and in the ease of developing correct > implementations of the formatter. If the goal of all this were just to write a formatter. So are you willing to say that as a general transformation engine XSL is not really useful and that it really is designed only to provide one part of a page composition engine? > I can always find a class of problems where a highly tailored solution is > cheaper than a general one (or where a specific programming language solves a > problem better than another language), however, this is not the true cost of > that solution. I must always ask: a.) Does the general solution cover my problem > space? If not use another tool or a mixture of tools. (However, because it > doesn't meet this criteria for your problems doesn't mean it isn't useful for > mine.) b.) Does it support my aggregate of problems at a lower cost than custom > tailored solutions to each individual problem. (However, because it doesn't meet > this criteria for your problems doesn't mean it isn't useful for mine.) c.) If > there is a significant subset of my problem space that can be answered by a > cheaper solution, shouldn't I adopt it? (YES). If the remaining problem space > can't be cost-effectively covered by the cheap solution, shouldn't I be allowed > to solve the problem using a solution appropriate to that problem space? (YES, > if truly cost-effective) The analysis is fine but the question still remains - how narrow is the solution space? The professionals from the transformation field are saying that XSL is too narrow for general transformation. I don't see any disagreement with this essential point. I think that in addition to joining me supporting CSS you probably should also be with me on the DOM and transformation as well. If you are willing to admit that all XSL can and should do is perform page composition I'll be only too happy to leave you in peace. > Claim 13 XSL stands no chance of being accepted on the web. > Response: I don't think this claim holds any water. IBM, Lotus, and > Microsoft have all announced support for XSLT. James Clark, Lotus and Microsoft > have released demonstration implementations. Several implementations of > formatting software have been announced and James Tauber demonstrated his at > WWW8 (two weeks after the latest Draft was available). I think there is clear > support for both the transformation and the formatting components of XSL, and > this is a fairly strong commitment for a draft specification. The feedback these > implementors and the WG are receiving do NOT substantiate Mr. Leventhal's > claims. People find this language useful, sufficient for most intended tasks, > and understandable (albeit non-trivial to learn). Improvements have been made to > the transformation language as a result of this substantive feedback." Well, I've been getting different feedback. I don't think we've heard from the broad web community yet. The W3C is not a purely industrial consortium and we have a self-interest as well as human interest in taking into account the effect of what we do on humankind for whom the Web has become the gateway to our collective knowledge. XSL is not a technology which is going to make participating in the Web easier or better for the majority of users and it is not to enable critical applications with additions to the infrastructure which do not exist today. > Conclusion > With every change in technology, there are a number of people who have fallen > in love with the status quo and attempt to derail the evolving new technology. > They say such things as: the new technology is some pipe dream of the future, it > is unproven, it is inefficient, it is hard to learn and hard to use. It is a > threat to what I know and love; something new I am being forced to learn. -- On > the new technology's inception, certainly all those things are true, but what > happens in 2 years? What happened when people moved from FORTRAN to Pascal? from > Pascal to C? from C to C++? from proprietary printer/typesetter languages to > PostScript? from PostScript to PDF? from proprietary composition systems to DTP? > from ink, rubylith and darkrooms to Illustrator and Photoshop? The same thing > will happen to the web's content and styling standards, the technology that > provides an answer to your problem will become the one that you use. Some will > fall to disuse, the remainder will live on and complement each other. > Mr. Leventhal appears to be saying that the web world can not be allowed to > advance beyond what it has today. Nor does it appear that he would allow the W3C > to define alternate approaches to a problem or define new approaches to problems > that are not well served by existing W3C Recommendations if there is any overlap > between this alternate solution and an existing Recommendation. Such a policy > would be crippling to the future growth of the Web. The most amusing thing I read in the whole XSL debate was the article by a gentleman who attempting to depict me as a grouchy old grandpa sitting in a rocking chair on his sagging porch, chewing on a pipe and grumbling "Dag-nabit, all those young whipper-snappers want to go and change everything, why in my day we didn't have all those darn-tootin fancy languages, why we wrote computer programs in Assembler and if it didn't work we just tapped on those darn transistor tubes and everything worked just fine, those were the days". Arguing against a technology which one considers a wrong turn and a serious one at that is not the same as being against technology progressing. Obviously. > If XSL provides a better mechanism to support online presentation, it is > clearly in the web community's interest. Not demonstrated. > If it provides a better solution to > print it is clearly in the web community's interest. First we need to define the problem as such and not a problem of general transformation or styling. Once we do that we need to know a little bit more about the formatting backend. And than we will decide if it is all worth it. > If it provides a common > mechanism to support print and online presentation it is clearly in the web > community's interest. If it does all of these, even better. There is no sense to "common mechanism". It appears that we have a good online presentation system, Mr. Deach argues that we need a page composition system, and there is no argument defending the idea that they need to be common. > From preliminary indications, XSL seems implementable and useful, thus Mr. > Leventhal's request to stop work on XSL (at least until CSS-2 is fully > implemented on every platform) is not only unrealistic, but is detrimental to > the web, since it would delay widespread support for XSL. > One size does not fit all. If you are happy with CSS, the DOM, and scripting > then use them; but don't prevent me from solving my problem. You are welcome to solve your problem. The question whether you should have a W3C Recommendation to do it with since W3C Recommendations, if they are to remain meaningful, become an indispensable part of the interoperable Web infrastructure. Michael Leventhal 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