Re: SGML and Forms

In response to an earlier point Paul Prescod wrote:
>>
>> The real question with forms is not how you should present them but
>> how you can pass information captured using them to applications.
>> At present niether DSSSL or XSL address this problem. With XSL
>> you can convert to HTML and then rely on HTML's use of CGI to
>> send messages to the message processor, but this is not a good
>> enough general purpose mechanism.
>
>Could you please comment on what you perceive to be the limitations of
>this system? HTML+JavaScript+HTTP+CGI seems to be well on the way to
>doing the things you ask of the system. We could reinvent another,
>better system, but a) why, and b) why as part of the XML effort?

I am not saying we need to reinvent what currently exists - simply improve
it to do what it currently does not do and then ensure that it is properply
integrated with the XSL ECMAScript facilities.

I am looking at this from the point of using XML for electronic
commerce/EDI.

There are three things we need to do that cannot be done with the exisring
IE4 implementation:

1) Locally validate entered values using sharable program modules (e.g. is
the entered value a valid date). For this ECMAScript would be ideal. but
there is no way of passing the value back to an ECMAScript module
(define-script) in the XSL script, it can only be processed using JavaScript
embedded in the form generated by the response. This is silly. If I already
have a module for doing this in my input reader I should be able to use the
same module to validate data entered into the form.

2) Check values against a local database/JDBC file and use the result to
generate outputtable data. For example, if I enter an ISBN number in a field
I want the associated author and title fields to be completed automatically
and the cursor to move to the associated quantity field. On submission all
of these fields would be treated as if they were manually entered data. At
present there seem to be problems with embedding FOR instructions within the
HTML output generated using XSL - for some reason this crashes IE4. In
addition there is no clean way of saying "load this retrieved data into this
field in the form".

3) The output needs to be stored at client side, as an XML message, before
transmission, and then to be sent in this form to the recipient as part of a
later, encrypted/secure transmission. Sending electronic commerce messages
as plaintext CGI is just not acceptable. Sending it to a server without
recording what was sent at the client is also not acceptable behaviour.

Martin Bryan


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