Re (2): Interactive XML

Martin Bryan writes:
For electronic commerce you need to be able to extend the simple form 
creation specification currently being considered to do things like: 
 
a) check that the value entered in a form conforms to a predefined lexical
value, 
or matches one of the entries in a referenced database (either on the local 
server, in cached memory or on a remote server) 
b) create menus whose lists of options can be created on-the-fly by selecting
options from 
a referenced database 
c) allow the selection of one item in one menu to change the contents of 
another menu (e.g. if I select Supplier  X then the list of options in the 
next menu changes to display only those items created by Supplier X) without 
having to make an additional call over the clogged network. 
d) allow sections of forms to be removed from, or added to, the display when 
a certain option is selected for a particular field. 
 
Most of these functions could be acheivable with a few extensions to ECMAScript,

provided that this general purpose langaguage is adopted by XSL as the main
means 
of associating programmable behaviour with XML elements. At present it is far
from 
clear that this will be the case. 
 
	From the perspective of the widget set, these requirements bring nothing new to
the table. If you said e-commerce needs fly-out, tear-off palettes or widgets
that look like buttons but act like dropdown menus (a la the Win95 Start
'button'), I would argue that you are wrong, but at least you would be advancing
the discussion in the right direction. 
	Interactivity does need to discuss tab order and accelerator keys, as has been
pointed out about HTML form tags and things like voice prompts for telephone IVR
and visually disabled applications. I thought the Tk suggestion was very
appropriate because Tk offers a good basic set of widgets, different from the
HTML set.
	It seems to me that the above requirements can be adequately handled by
ECMAScript function calls embedded in event trigger attributes (a la
onLostFocus="javascript:validate(this);") and DHTML tricks such as playing
around with the z-order of <div>s. So we might want to talk about whether the
set of trigger events is adequate or not, but the code snippets I'll build/buy.

	However, I think the whole discussion of what is, in effect, UIML, is somewhat
inappropriate to this list. We don't need this or any other random set of flow
objects rammed into any particular rev of the XSL spec. We need a general way to
declare which flow objects the style sheet is using and where to acquire a
rendering engine for that set. Then the W3C will be out of the flow object
business except for the case of HTML, which is a standard it owns. Then Adobe
can sell a package of PGML flow objects and a style sheet can turn database
output into hyperlinked infographics, and the milling machine industry
consortium that defines Numeric Controller ML can rest easy, knowing that the
software suppliers that support that industry will implement the flow object
library that will allow database output to be rendered as milled metal, XML
document to engine block via a style sheet.
Cheers,
David vun Kannon


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list