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

Status

()

Core
XML
--
enhancement
15 years ago
3 years ago

People

(Reporter: Manko, Assigned: Heikki Toivonen (remove -bugzilla when emailing directly))

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
Future
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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:
(Reporter)

Updated

15 years ago
Blocks: 35995
(Reporter)

Comment 1

15 years ago
Created attachment 115128 [details]
Simple XSLT to transform OOo -> XHTML

This is a simple and rough, but really working XSLT to show OpenOffice.org
doicuments.

Thanks for Jason Johnston (http://lojjic.net/)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
(Reporter)

Comment 5

15 years ago
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.
Status: UNCONFIRMED → NEW
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.
(Reporter)

Comment 8

15 years ago
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.
(Reporter)

Comment 10

15 years ago
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.
(Reporter)

Updated

15 years ago
Keywords: helpwanted
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 16

14 years ago
Only for general information, there also is an OOo-issue:

<http://www.openoffice.org/issues/show_bug.cgi?id=22406>

Rainer
Comment hidden (obsolete)
(Reporter)

Updated

14 years ago
Blocks: 114376
(Reporter)

Comment 18

14 years ago
Adding RSS in summary
Summary: General module to show widespread XML formats: WML, DocBook, OpenOffice.org etc. → General module to show widespread XML formats: WML, RSS, DocBook, OpenOffice.org etc.

Comment 19

14 years ago
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?
(Reporter)

Comment 20

12 years ago
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.

Comment 21

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

Comment 22

11 years ago
(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
Comment hidden (me-too)
You need to log in before you can comment on or make changes to this bug.