RE: [xml-dev] Symbol Grounding and Running Code: Is XML Really Extensible?

["Hunsberger, Peter" <Peter.Hunsberger@stjude.org>]

Alaric B Snell <alaric@alaric-snell.com> proposes:

<snip/>

>   Clearly, this process can be generalised with an extensible lookup 
> table to allow one to ship a module for web browsers that 
> allows them to 
> display, say, directly embedded SVG or RDF (as a graph of clickable 
> links for nodes and arrows between them or something).
> 
>   XHTML itself would be just such a module; so some other 
> renderer could 
> find bits of XHTML embedded in it's input document as labels or 
> something and pass control (via the lookup table) to the 
> XHTML renderer 
> for those.
> 
>   Thus, the web browser's rendering engine would boil down to 
> invoking 
> the correct module for the namespace of the root element and letting 
> that module handle dispatch to other modules where appropriate.

A small nit: you'd want each module handing dispatch handling back to
the main "browser rendering engine" when it hit a namespace other than
it's own.  That way the handling of module lookup would be done in only
one place instead of each module...
 
> The hard part for being able to define an extension architecture for 
> every XML application domain (rendering, searching, etc) is 
> choosing a 
> generic API and a general meaning of 'embedding' for that application 
> domain. Can this in general be done? I'd say "probably". 

Watching the developments in Aspect Oriented Programming (AOP) go by I'd
say the likely hood is more than "probably": eg. the JBoss
implementation (and likely others?) allows XML definitions of method
overrides that allow you to change the parameter structure of a method
and give you (among other things) the equivalent of multiple inheritance
if you need it.

> However, expect 
> problems where people overspecify stuff and accidentally produce 
> non-extensible module APIs (perhaps something more general 
> than the CSS 
> box model is required to base rendering upon. Perhaps XSL-FO would be 
> better).

The rendering issue is separate from the API extension issue, and
perhaps harder: I'd guess that you want something more generic such as a
than simple boxes, Bezier curves in addition to lines at least?