Lists Home |
Date Index |
- To: "Alaric B Snell" <firstname.lastname@example.org>
- Subject: RE: [xml-dev] Symbol Grounding and Running Code: Is XML Really Extensible?
- From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
- Date: Thu, 14 Aug 2003 10:06:41 -0500
- Cc: <email@example.com>
- Thread-index: AcNiNP1g6hBJxtC1Rcezd+84oLt8GwAPYDzQ
- Thread-topic: [xml-dev] Symbol Grounding and Running Code: Is XML Really Extensible?
Alaric B Snell <firstname.lastname@example.org> proposes:
> 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
> 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
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?