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

RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?

• To: 'Micah Dubinko' <MDubinko@v...>, xml-dev@l...
• Subject: RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?
• From: Didier PH Martin <martind@n...>
• Date: Thu, 27 May 2004 22:25:33 -0400
• Importance: Normal
• In-reply-to: <148BAF3C77417F4AA53ED7941743D0190F49BE@v...>
• Organization: netfolder
• Reply-to: martind@n...

Hi Micah

> For it to be useful, it would have to have widespread acceptance, a la
> exslt.org. In fact, I've talked to the EXSLT folks before, and they
> weren't openly hostile to the idea.
> 

Or maybe get some mapping defined as XSLT stylesheets that can be imported.
Actually, I found that in order to map collection browsing (treeView and
TableView) to HTML or XHTML, source domain model language can create a
hierarchy of embedded DIVs (treeView) or simply a table (tableView). I
managed to map RSS (1.0 and 2.0) and Xlink (extended) into treeView
component for both IE and Mozilla. You can get a sample in a work in
progress work at: http://www.netfolder.com/pdml/webtop/desktop2.html  it's a
portable desktop implementation. The treeView located inside the start
button is created from xlinks inherited elements. Hence, this treeView
understands a composite pattern based on xlink attribute inheritance. 

My actual difficulty is to create portable scripts for both mozilla and IE.
However, since both Mozilla and IE maintain a triple DOM (XML + XSLT + HTML)
it can be possible to bind any HTML element back to its XML element (got the
inspiration from Xforms ;-) and got some help from members of this list on
how to extract the xpath of mapped elements). In fact, I am already doing
this in the tree by adding a new attribute to the DIV (bind="xpath"). Hence,
scripts can add new editing behavior to the embedded DIV and update the
local XML document using this attribute to find the associated element. The
updated XML document can be sent back to the server with an HTTP GET or POST
(when using a REST architecture) or each editing function can trigger a SOAP
function call. To update the local model or invoke a remote call, the
treeView component has to call an ECMA Script object supporting a standard
interface (a specified set of functions).

So, it can be done also without having to modify XSLT and using portable
stylesheets that can execute on the client side in both Mozilla and IE.

In the process I am also thinking on how to define an abstract treeView
pattern. When collections are structured in hierarchies a treeView is
recommended. When collections are structure as an array or table a simple
table view is recommended. Since a table is already defined in HTML and
XHTML, what is left is a treeView and some other widgets not already defined
in HTML nor are defined in XHTML. But the most important part is to find a
way to define new widgets so that the framework is eXpendable. This is what
made power builder and visual basic powerful. If we find a way to define
components or mapping strategies we are on the right path to build powerful
rich internet applications that run on the client side without necessarily
needing a server for every user interaction. Powerbuilder and visual basic
did that with an interface definition. Maybe this can be done with HTML and
XHTML with mapping definitions (Ex: xlink:type="extended" collection of
locators into a collection of DIVs).

Thinking even more about the subject, we can say that it's an application of
model driven architecture. A domain model representation implemented in XML
transformed into a visual domain implemented in HTML. It's a model to model
transformation and the transformation tool is XSLT. It's quite different
form the model-view-control pattern but this MDA approach is well adapted to
XML technologies. As an example we can define a set of transformation rules
to transform xlink extended collections of locators into collection of DIVs.


Actually I am not as lucky as EXSLT and this project is funded by my own
money...and driven by my own curiosity and frustrations about a web jammed
to a paradigm as old as the 60s (server centric applications and dummy
terminals)

Cheers
Didier PH Martin

• References:
  • RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?
    • From: "Micah Dubinko" <MDubinko@v...>

• Prev by Date: RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?
• Next by Date: Re: Early Draft Review: XQuery for Java (JSR 225)
• Previous by thread: RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?
• Index(es):
  • Date
  • Thread