Subject: Re (2): Interactive XML From: dvunkannon@xxxxxxxx Date: Mon, 29 Jun 1998 16:35:10 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Restricted HTML elements in out, Chris Lilley | Thread | Language choice (was: Re: Interacti, Brandon Ibach |
Re: Interactive XML, Paul Prescod | Date | Language choice (was: Re: Interacti, Brandon Ibach |
Month |