[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Symbol Grounding and Running Code: Is XML Really Extensib

  • To: "Alaric B Snell" <alaric@a...>
  • Subject: RE: Symbol Grounding and Running Code: Is XML Really Extensible?
  • From: "Hunsberger, Peter" <Peter.Hunsberger@s...>
  • Date: Thu, 14 Aug 2003 10:06:41 -0500
  • Cc: <xml-dev@l...>
  • Thread-index: AcNiNP1g6hBJxtC1Rcezd+84oLt8GwAPYDzQ
  • Thread-topic: Symbol Grounding and Running Code: Is XML Really Extensible?

RE:  Symbol Grounding and Running Code:  Is XML Really Extensib
Alaric B Snell <alaric@a...> 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?


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.