Open Bug 194351 Opened 17 years ago Updated 5 years ago

General module to show widespread XML formats: WML, RSS, DocBook, etc.


(Core :: XML, enhancement)

Not set





(Reporter: sinchi, Assigned: hjtoi-bugzilla)


(Blocks 1 open bug)


(Keywords: helpwanted)


(1 file)

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, documents, cHTML and probably other ones by transforming to XHTML
"on the fly" via XSLT or inserting  <?xml-stylesheet?> instruction in document

I hope, this doesn't require hard coding, but will be very usable.

Also we should have modules to unzip documents (we could use
zlib) and to decompile WMLC documents (see bug 35995 comment 30 for details).

Reproducible: Always

Steps to Reproduce:
Blocks: wml
This is a simple and rough, but really working XSLT to show

Thanks for Jason Johnston (
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.
Ever confirmed: true
Target Milestone: --- → Future
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.
Keywords: helpwanted
Only for general information, there also is an OOo-issue:


Blocks: 114376
Adding RSS in summary
Summary: General module to show widespread XML formats: WML, DocBook, etc. → General module to show widespread XML formats: WML, RSS, DocBook, etc.
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 ( 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
QA Contact: ashshbhatt → xml
You need to log in before you can comment on or make changes to this bug.