Hi Greg,
 
Check into XForms, a W3 standard in the works. That community is all about XML->GUI->XML processing. Google should get you lots of good links. The rest of this note is just me musing on the state of the art.
 
It is not possible, in general, to automatically turn a set of arbitrary XML documents into a decent GUI editor given just the documents and schemas for the documents. Whatever you do will take this form:
 
  XML storage->XML-to-GUI converter->something user edits->GUI-to-XML converter->XML storage
 
If the "something user edits" is, say, HTML+_javascript_, a programmer or three can sit down and churn out the XML-to-GUI and GUI-to-XML converters in some amount of time, using their favorite server programming language.
 
But each successive application constructed like this is just as much work as the first!
 
Early server-side XSLT advocates promoted pipelines like this:
 
  XML storage->XSLT processor->something user edits->GUI-toXML converter->XML->XSLT processor->XML storage
 
This pipeline is easy to criticize. The rightmost XSLT stage seems to be gratuitous. If you have to hand-write a GUI-to-XML converter why don't you just write directly to XML storage and cut out the middleman? The leftmost XSLT stage, though programmed at a higher level, is frequently slower than the hand-written XML-to-GUI stage it replaces. Moreover, if the XML storage is really a relational database, the left part of the pipeline actually replaces:
 
  Database->Relational-to-GUI-converter->
 
with:
 
  Database->Relational-to-XML converter->XML->XSLT processor->
 
which is not only slower it is frequently an order of magnitude or so slower. Likewise, on the righthand side of the pipeline. Relational database fans who are hostile to XML have a field day poking fun at this unnecessary complexity.
 
But _if_ an application is really XML-in, XML-out (or if the relational database can, as some can today, efficiently pretend to be XML-in, XML-out) then XForms might play a reasonable role, as it is also an XML-in, XML-out "process". The XSLT steps are still needed, but you can put together a pipeline like this:
 
  XML storage->XSLT processor->XML->XForms->XML->XSLT processor->XML storage
 
The inner XML is needed to map between presentation-oriented and storage-oriented representations of the same information. The non-inconsiderable XSLT overhead can be reduced somewhat by compilation, and the whole thing, if not quite as clean as I have drawn it, is at least not downright silly.
 
A hoped-for virtue of the XForms approach is that it can push the entire XSLT processor->XML->XForms->XML chain of conversions into the client. This leaves the server with only a relatively high-level XSLT input processing stage, and the XSLT can be compiled to make the comparison to custom code less odious. The result could be a considerable reduction of complexity on the server side. It may be too soon to catch this wave, but something to keep an eye on.
 
Bob Foster
----- Original Message -----
From: Greg Hess
Sent: Wednesday, September 17, 2003 2:28 PM
Subject: [OT]-- Editing XML

Hi All,

 

I am new to XML, XSLT, schema so please bear with me.

 

I have been assigned to build web application that needs to alter many 3rd party defined XML data structures. I would like to take a 3rd party XML data structure and defined XSLT to create a HTML form for editing the underling XML data structure. Only requiring basic input validation maybe from a schema. When the form has been completed and submitted the XML data structure would be recreated with the new input values. I need to do this in a generic way so that the same application can process and edit any defined XML data structure.

 

                                    XML HTML FORM XML

 

Can I do this?

 

Are there any tools out there that enable this?

 

Could a 3rd party define a XML data structure and XSLT that would create a HTML form for editing the data structure?

 

Any comments/input is greatly appreciated, I have been assigned this task and have no idea if it is possible or where to start.

 

Many Thanks,

 

Greg Hess

Software Engineer

Wrapped Apps Corporation

275 Michael Cowpland Dr.

Suite 201

Ottawa, Ontario

K2M 2G2

Tel: (613) 591 -7552

Fax: (613) 591-0523

1 (877) 388-6742

 

<<image001.gif>>

Reply via email to