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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Converting a DSSSL Stylesheet i, Jonathan Marsh | Thread | Re: XML Rendering Engine API, Chris Lilley |
RE: Converting a DSSSL Stylesheet i, Jonathan Marsh | Date | New XSL processor, Frank Boumphrey |
Month |