[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Venting
Hi. An interesting post, and one that gave me pause for thought. I believe it's the WGs aim to get the whole package out by August including FOs, I am not aware of any slippage in this area, but then again I haven't been tracking this very close the last month. As to when FOs will be supported, certainly not until tehy become a final Rec. I would urge however that we not persue the arguement that "That bit's going to be a while comming, so we need not bother". If we applied this attitude to standards we would have precious few, including CSS2. CSS is easier than FOs, but the equation in one of CSS+HTML, which even at a simple level I would suggest is not, and if one where to take exception to that I would suggest that expressing pagination in CSS+HTML is not simpler. You're arguements don't even begin to address the needs of our brothers in print design, they wont be impressed by your suggestion that they should use CSS+HTML. Your point d) seems to lead on to suggest that the standards should only follow implimentation, This approach again would kill nearly all the Web standards we have. Also movements like WaSP have been established due to the outrage at the ensuing chaos of implimentation running ahead of standards, hence the nightmare that was HTML 4 + CSS browsers implimentations. You then return to say 90% of all implimentation are transformative, so that can be taken as the definative decisiion. I would suggest as I have before that this is a rediculous stance to take for a standard not yet complete, aspecially for FOs. Everybody knows that neither MS nor NS will impliment FOs until they're set in stone, as it requires serious reworking of aspects of their browsers. They aren't going to do this while stood on shifting sand, they'd be nuts to. I regard your line of reasoning here as a non-arguement and against all reasonable expectations. On your own practical working practice, I simply respect that that is what you like and percieve to be "a good thing", and I wouldn't seek to knock it at all, we are all entitled to choose our prefered methodologies. What I will add by way of expressing my own preferences is that in the work I do I would like to kill HTML stone dead. As a mark-up expression it is now more hinderance than a help. This is evidenced by the fact that I now only use two elements from HTML, predictably, DIV and SPAN, the rest have little bearing to what I'm matking-up. I am by using DIVs and SPANs efffectively creating my own FOs. I would prefer there to be a standard set of FOs..... but this arguement is already well expressed by others elsewhere. Cheers Guy xsl-list@xxxxxxxxxxxxxxxx on 02/10/99 10:21:47 PM To: xsl-list@xxxxxxxxxxxxxxxx cc: (bcc: Guy Murphy/UK/MAID) Subject: RE: Venting 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 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
|