User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 Build Identifier: It will be nice to have module to show widespread XML formats: WML, DocBook, OpenOffice.org documents, cHTML and probably other ones by transforming to XHTML "on the fly" via XSLT or inserting <?xml-stylesheet?> instruction in document header. I hope, this doesn't require hard coding, but will be very usable. Also we should have modules to unzip OpenOffice.org documents (we could use zlib) and to decompile WMLC documents (see bug 35995 comment 30 for details). Reproducible: Always Steps to Reproduce:

This is a simple and rough, but really working XSLT to show OpenOffice.org doicuments. Thanks for Jason Johnston (http://lojjic.net/)

I hope that this doesn't require hardcoding. We are getting XML document, adding <?xml-stylesheet?> instruction then showing in browser window. I have made it manually many and many times for WML and OOo files, all works fine. See screenshots at bug 35995. I have posted this bug just because I guess this would be cheap in realization but extremelly useful feature.

This sounds like a mozdev project to me (or actually, several mozdev projects). I'd LOVE to be able to install XPIs for DocBook and OpenOffice. Some things that would probably make this easier is if we first implemented bug 98413 and bug 92452.

I agree with heikki -- we should provide some hooks for this in the core, but specific transformations should not ship by default, imo.

Maybe, but it seems to me that few quantity of tiny XSLTs (WML and probably OOo) and related CSS an JS (see bug 35995) might be placed in default installation: their total uncompressed volume is about 28K. Also I have occasion to hear about plain and tiny XSLT to transform DocBook/XHTML. Opera already has WML support (worse than proposed in bug 35995, btw ;) and some my friends consider this to be serious advantage. In nearest future we'll face with the challenge of XHTML 2.0 - but W3C provides XSLT to transform it to XHTML 1.1, and we could use this bug for XHTML 2.0 support as a first approximation.

It's not just a matter of size but also a matter of maintaining it. Are those XSLTs very well tested and non-buggy? Oh, and hyatt has an xbl implementation of most of XHTML 2.0 already... it's much easier done and more effective in XBL than XSLT.

I have tested XSLT for WML on several complicated WML pages with forms. Generally all was OK. See bug 35995. All known errors rided on incorrect syntax of source XML: * empty lines before <?xml?> declaration; * incorrect entities such as &nbsp; - not described in WML DTD; * unclosed tags such as <img> instead of <img/>. I also has tested attached XSLT for OpenOffice on quite complicated Writer and Calc documents (I have used OOo 1.0.1 Russian ALT2 build by AltLinux Team to create it). I have extracted and transformed only content.xml from archive. No errors appear. All text content, headers and tables are being shown OK inspite of language. Simple character formatting (bold, italic) also OK. Paragraph formatting, styles and also built-in objects (such as images) are omitted.

Boris, do you have pointers for the XHTML 2.0 XBL?

"hyatt's tree".... I'd mail him and ask.

Only for general information, there also is an OOo-issue: <http://www.openoffice.org/issues/show_bug.cgi?id=22406> Rainer

Adding RSS in summary

Note that some XML formats don't need to be converted to XHTML at all to make them presentable. There's nothing wrong with using CSS to style XML. I might also prefer to see a solution that works for multiple XML namespaces in a single document. Many of these document types are fairly self-contained and don't include content from other XML namespaces, but it might be interesting to have one XML document type embedded within another one. Is it worth considering a mechanism for getting all of that rendered correctly? Is that even possible?

Of course, if CSS is enough, we don't need an XSLT. I would see approximately that algorithm: 1. Browser gets a file and recognizes it by a mime-type or an extension. 2. If file is in a zipped format (such as ODF), browser decompresses it in a temporary dir and gets a main content file. 3. There is a correspondence table between a file type and XSLT or CSS (and maybe a DTD) in browser prefs. DTD, XSLT or CSS may be placed in a res:// or in a chrome directory. Items in a correspondence table (and files in res:// or chrome dirs) may be added by an XPI packages. 4. Browser adds an XSLT or CSS instruction into an XML header and shows file in main window. Additional files for parsing (JavaScripts, XBLs, images, CSSes etc.) may also be placed in res:// or in a chrome directory. About embedded XMLs with additional namespaces: if browser can interpret corresponding XML format natively (XHTML, SVG, MathML etc.), we should render it unchanged, and correct XSLT should copy it unchanged into the output by <xsl:copy/>. If browser can interpret embedded XML via this bug, I guess, there should be a mechanism to invoke corresponding XSLT or CSS.

wmlbrowser extension (http://wmlbrowser.mozdev.org) uses XSLT and nsIStreamConverter to convert wml to HTML for display in the browser.

(In reply to comment #9) > It's not just a matter of size but also a matter of maintaining it. Are those > XSLTs very well tested and non-buggy? For OOo, I dont think maintenance will be an issue, as per one ooo conference video OOo uses XSLT transform to do html export feature in OOo, so we could ask them for the latest XSLTs