XML Rendering Engine API

Subject: XML Rendering Engine API
From: "David Peterson" <david.peterson@xxxxxxxxx>
Date: Sat, 6 Jun 1998 09:55:02 +1000
Hello everyone,

I've been contemplating working on an XML browser and/or editor, and it is
quickly apparent that the rendering engine will be one of the most difficult
parts.  The current XSL Recommendations document specifies a very powerful,
and thus complex style language.  This is a good thing, but it means that
not everyone will be able to (let alone want to) implement it.

Also, XSL will not be the only style language for XML.  I believe Netscape
has already stated they will support CSS2 for XML, while MS will support
XSL.  As an implementor, it would be good if there was a standard API, so
that you could plug any rendering engine that supported it into your program
with ease.

The XML Rendering Engine API (XREA - pronounced X-Ray)
======================================================

Requirements (not in any order):

1. XREA will conform to any W3C activity involving XML and Style (ie XSL,
CSS).
2. XREA will not be style language-specific.
3. XREA's specification will not be platform- or implementation
language-specific.
4. XREA will support real-time modification of the rendered data - including
changes made by programming or user input.
5. XREA will provide for multiple implementations to be used within the one
application.
6. XREA will provide hooks for WYSIWYG editors to use the engine.

Details:

1. This is a given.  The DOM is an important aspect of this, since it will
probably be the basis of any real-time modification.  This may also involve
specifications like XLink and XPointer - although that is possibly outside
the scope of the API - the actual implementations would handle that.

2. The API must be generic enough to allow any style language to have an
engine built on it.

3. This may be the most difficult, since graphics are one of the most
diverse parts of a platform/language.  The only solution I can think of is
to have a proxy interface that can do what we need, and then maps back to
the 'real' graphics implementation.  Alternatively, there could be a
'Rendering' section of the spec that is not platform-independent.

4. This will most likely be through the DOM programmaticly, perhaps via
ECMAScript, or by user input.

5. Basically, this means a program should be able to iterate through any
provided engines and determine if it supports a provided style language, and
then render it.  Basically, there would be some kind of
'IsStyleLanguageSupported" function available.

6. I'm not sure if this is feasible, but it would be nice, since the editor
display would actually look like it will in the browser.  Currently, I don't
know of any WYSIWYG editor that does this - MS's FrontPage 97 looks
completely different to FrontPage 98, and neither of them look exactly like
they do in IE, let alone Netscape.  Since the content will be dynamically
editable anyway (point 4), it would mainly involve letting the user (and the
programmer) know where the caret is, and what's selected.

There need to be more and better defined goals, and some of the current ones
may not be practical.  I'm not sure this is possible, wanted, or needed, but
I'd really like it.  Your comments are appreciated.

David Peterson


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread