Subject: RE: Venting From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Wed, 10 Feb 1999 14:21:47 -0500 |
Hi Guy, I'll tell you my biggest concerns: a) That the final spec that includes formatting object won't be out before next year. b) There won't be any browser that includes XSL FOs until one or two years. c) CSS is easier to use for Formatting objects on the client side and browsers are catching up CSS1 full implementation. So now imagine for CSS2. d) A spec is nothing only implementations created by manufacturer is something (a pragmatic point of view). So, Why get mad about manufacturers who created real stuff? big manufacturers have interest that the spec isn't fully completed until there ready. Small manufacturer don't. Status quo favor big manufacturer and re-enforce actual status quo situation on the market. So, the question is: all ISV happy that more and more the software ecological system is more and more occupied by single specie? Status quo encourage this by putting delays in the process. But also I'll tell you what can re-assure me: a) nothing speak more than action. If 90% of all XSL implementations including the big guys implementation are XSL transformation then that's it, for most of the population XSL is transformation only. Manufacturer should not refrain themselves from calling their implementation XSL even if it only contains the transformation part. b) XSL will be more popular on the server than on the client. CSS will be more popular on the client. XSL will be mostly used to transform XML into HTML+CSS for very practical reasons. c) The majority of the market on the server side is owned by apache and therefore there is room for manufacturers others than Microsoft and AOL (Hoops. sorry, Netscape) to provide XSL engines and that is good for ISVs. As soon as XSL reach the big developers market, demand for new features will abound and these engines will move from ideal driven to market driven. d) W3C won't necessarily favor small manufacturers (ex: look at W3C style sheet page, only certain manufacturers links are present and do not reflect all current implementations. There is a certain censure) W3C will favor first its member and we shouldn't expect more it is not in W3C gene to do so. If manufacturers do some form of sane coopetition they have more power than they think they have. e) XSL transformation already showed its utility and with some ingenuity could do a lot more. Again, action talks, concrete example will provide more to potential users than concise specs. So, we demonstrated that our group could be as divided and diverse as W3C workgroup. This is a good thing, we don't suffer from group think. If this group where under IETF hospices it would have already improved a lot the specs. In one word, I am impressed by the quality of this group. Now practical things: I am experimenting on domain language translation using XSL, so far, I am surprised by the potential this language has for this. If section 2.2 stays, or if implementations keep that (because it is a good thing) we have certainly some potential here. I am using more and more HTML+CSS as a formatting language. I like the voyager module segmentation that is re-using Hytime modele mechanism. So, I can pick the proper formatting object from these modules. So, in my practice, I got used with XSL for transformation and HTML+CSS for rendering. I don't care about XSL fOs they don't give more than what I have now with HTML+CSS and I don't have again to learn new stuff but re-use my knowledge of HTML+CSS (If we speak of knowledge management, knowledge re-use is also very economical and I guess that a lot of Web developers will think the same). Anyway, a browser understanding XSL FOs is not until 2 to 3 years from now and a market having 90% browsers with XSL FOs not until... You got the point? I am also experimenting to create macros that implements Formatting objects for other formats (tex, rtf, etc...) the idea is to use these macros within templates to create the desired output. From the specs (actual, as written) it should be feasible. I am trying this on different implementations, so far, didn,t went far on this, most of them do not work well with macros. (macros could be very demanding for XSL interpreters as I already experimented with DSSSL macros that blown away Jade). In one word, as long as already existing implementations (with source code or binaries) support transformation, what I really use is the transformation part. So, for me, actually as it is for 90% or more of actual users of XSL, XSL is de facto a transformation tool and CSS+HTML a formatting/rendering tool. I am also writing a paper that compare CSS, XSL and DSSSL. To write this help me a lot to understand the strengths and weaknesses of each. And also by keeping a eye on practical ends, put these into perspective like: using DSSSL and HTML+CSS as formatting objects, same thing for XSL, The difference I have if I use HTML formatting object stand alone and the same objects with CSS (either with the style attribute or the class). The fact that actual browsers formatting language is HTML+CSS put transformation language into a different perspective, As soon as DOM 2 is implemented, a browser may be used to render any language and that is interesting too because it opens the door to other formatting/rendering languages. also on the work articles on: How to use browsers to create SGML electronic books (like ATA 100, etc...), XML based e-books, How to use topics maps to organise a collection of XML/SGML documents (also alternative formats like PDF, EPS, etc..) In all these activities I use XSL as a tranformation tool because I have plenty of tools to experiment with. This is not the case with XSL formatting objects. Sincerely, Guy, did you do any stuff with XSL formatting objects? I doubt. So, XSL transformation has already a big momentum and that is not the case with XSL formatting objects and that is obviously for practical reasons. Lessons to remember: Actually if you look at most sites talking about dsssl they also mention Jade as the implementation (also in other parts of the world they have other Jade derived tools). Jade is often 99.5% of the time presented as a DSSSL implementation even if it don't support the tranformation part. So I don't think that manufacturers should be afraid to call their implementations XSL. We already have jurisprudence that the market give the name to real stuff not the piece of paper that inspired this. So let's call the transformation part XSL and for most people, formatting objects will be a version 2 and probably XSL will be more popular as a tranformation tool. W3C get a good occasion to show some common sense but a chapter is not governed necessarily by that but also by political pressure of its member and the limitations of the charter. Manufacturers int his story already showed that they have common sense. Of course, they have a market to serve. Now let's go back to my lab, I repect your desire for status quo and I still support Paul's efforts to gets things moving and clarified. Always two forces present in any group. My hope, the future of XSL is more in the hands of those implied in the action. Regards Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Venting, Guy_Murphy | Thread | Re: Venting, Keith Visco |
Re: Venting, James Tauber | Date | The Peace Process: DOM and namespac, Rick Ross |
Month |