Re: XML Rendering Engine API

[Chris Lilley <chris@xxxxxx>]

David Peterson wrote:
> 
> 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.

You betcha

>  The current XSL Recommendations document 

small correction: there is no XSL Recommendation. That is due in July
1999. There is a CSS2 Recommendation, and the first Working Draft of XSL
1.0 is due in July 1998.

> 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.

Implementation footprint is considered secondary to generality and
expressive power for XSL. For example, requiring implementations to have
access to the entire parse tree of the document imposes some minimum
implementation requirements, but also allows clean, regular and
arbitrarily complex searches on the document tree when constructing the
rendering objects.

> 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. 

Have they said they will not support CSS?

>  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.

Sounds interesting.

> 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.

That is a well thought out but substantial set of requirements. Glad to
see you note the additional requirements of editors and of dynamic
behavior.

> 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.

Tricky to acheive in practice since it depends on the underlying model.
However, ongoing work at W3C is producing a harmonised CSS/DSSSL model
in which both CSS and XSL can be expressed. So, while not being generic
to any possible style labguage, this should at least be achievable for
CSS and XSL.

> 3. This may be the most difficult, since graphics are one of the most
> diverse parts of a platform/language. 

Yes. For ideas, have a look at the FreeType truetype renderer which is
platform independent (and includes source).

http://www.physiol.med.tu-muenchen.de/~robert/freetype.htm
http://www.physiol.med.tu-muenchen.de/~robert/projects.htm

>  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. 

Another possibility is to write to an offscreen bitmap and then use a
platform-independent wrapper around platform-specific ways to blit that
onto the screen.


> 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.

And whether something in the parse tree was (part of) an entity or not

> 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.

I would be interested in seeing this idea developed further.

--
Chris


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