Subject: RE: Formatting Objects considered harmful From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sat, 17 Apr 1999 12:05:57 -0400 |
Hi John, <Comment> As for those who've never used either PDF or FOs, I still don't quite understand why they'd *want* to use FOs alone. To grok XSL FOs, they've got to grok XML itself. By the time they get that far, if they remain determined to create FO castles in the air, as it were, neither we here nor the W3C will be able to stop them. I don't want to expend any energy to stop them. There won't be enough of them to worry about. So I guess my main question is still, WHY would someone want to build documents in an FO-only way? I still think this is a straw-man argument -- it attacks the spec for failing to legislate against an extremely unlikely crime... a crime almost certain to be committed by no one but those on the Dadaist fringe of content developers. </Comment> <reply> I think that this danger can happen only if a major manufacturer with a sufficient market share publish a product which produces FOs. If we look at these manufacturers: a) Microsoft - they choused an other path ( a mix of semantic XML, non semantic XML and HTML+CSS) b) Corel - They choused a XML/SGML/HTML path. I think the probability that this happens is quite low. However, I see tremendous resistance to go from HTML to XML for massive publications (at least for several years) on the web. However, I see XML strongly making its marks on EDI and consumer e-commerce. Also, XML may be the next step for SGML shops because the tools are cheaper than actual SGML tools and still have SGML advantages. A major argument for SGML shop is the huge difference in cost of a SGML aware browser and a XML aware browser. I think, that we'll see a transition period where SGML/XML parser will be included in actual browsers. This could allows the inclusion of Hytime and TEI link architecture. However the main difference would be that the rendition engine would be a browser (IE or Mozilla) instead of the Synnex engine (which is actually a monopoly for SGML rendition engine - using, of course the same criteria to define a monopoly as used against Microsoft). For Browsers, the underlying model (where a lot of investment have been made) is HTMLDOM or XMLDOM + CSS. In fact, If you look at Microsoft or Mozilla engines, both made or are making significant development investments in CSS objects. For Mozilla especially, the cost to move to new FOs is simply not affordable because there is no big pockets behind the project anymore . From the Microsoft perspective, they could embrace XSL FOs to kill once for all the competition but this would be a big strategic mistake that I doubt they would do now. As Intel is doing today, they now have to keep a certain level of competition to prevent Feds intervention. So, knowing that supporting XSL FO would kill Mozilla not able to re-invest energies to start new development on a different FO model. I doubt they would make that move. So, my bets are that CSS objects are here to stay for a long period of time. CSS being an easier language to learn and that could easily wrapped with property pages, CSS popularity will re-enforce this situation. XSL could be used for more sophisticated formatting or for off-line formatting and therefore would compete with an other standard language like DSSSL and the two actual main manufacturer owned languages omnimark and balise. These two language still have a lot of advantages like being able to link to relational databases. XSL and DSSSL are weak compared to these languages on this point. On the server side, xsl will have to face some strong competition form Perl and ASP. XSL language may have tremendous opportunities but its strong actual grounding in style formatting, may also be its worse enemy. However, in the future, XSL may evolve toward pattern matched processing or event based processing for server side scripts. Because on the server, there is no strong standards for server side processing, XSL may have strong potential there. Also, the popularity of XML EDI may require server side processing. How long will it take for XSL to move from a simple style language to a server side script language. I don't know. But this is where XSL may have the greatest opportunities. I do not want to say that XSL is doomed to failure. No, just to say that if we look at the marketing dynamics, the time it takes for standard organism to learn and react, the goals of the players bringing real stuff on people's desktop, XSL and either its FO or transform part have to be thought within a broader perspective. This does not remove the qualities of this language but I just try to put things into the bigger system they are part of. Conclusion: I am not too afraid by XSL FOs and their bad usages. I am more afraid of the lost standardization possibilities lost because XSL is restricted to a simple style language. Languages like omnimark (also envent based or pattern matched languages) showed that linkage to data base can make the whole difference especially if you have to process a XML EDI document. I am more afraid of the standard organism learning curve an the natural balkanization that occurs because of the charts, consensus to build with members, etc... How long, if can take for the community to recognize XSL as a great candidate for server side scripting standard? I don't know? So, I'll continue to fill my notebooks with historical facts and continue to observe the big system where this thing happen and how some decisions may impact our computer world. </reply> 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: Formatting Objects considered h, John E. Simpson | Thread | RE: Formatting Objects considered h, John E. Simpson |
Re: Formatting Objects considered h, John E. Simpson | Date | RE: Formatting Objects considered h, John E. Simpson |
Month |