Jonathan,

Many thanks for responding to my points.

>a) I don't know why you are trying to use XSL for validation.  I would
>expect either your data source (XML from a database?) to only generate
valid
>values, or your input mechanism (DHTML) to do validation.  XSL seems like a
>generally poor place for trying to do this.

You might want the routine to be in XSL as part of a precheck before loading
parts of the received message into a database. In the example I have in mind
I validate incoming dates so that I can do a date-to-string conversion that
will change the ISO8601 date into something that is readable. (MSXSL does
not validate the date, so entering 19980230 gives you a displayed data of
2nd March 1998!). I would like to use the same routine to display a readable
equivalent of a date which is entred in ISO8601 in a form so that the form
filler has a readable check that he has entered the date correctly.

>b) A separate issue is sharing code.  XSL could easily be extended by
>encapsulating the shared ECMAScript in a separate file:
> <define-script src="fancyScript.txt"/>
> <SCRIPT src="fancyScript.txt"/>
> This looks like a minor addition that would have some value, but not
>a huge show-stopper in the XSL language or even in the MSXSL Preview
>release.  Am I missing something or is this just a nit?

No - this would be great, providing that the DHTML and ECMAScript sides were
fully compatible.

>c) XSL could eventually be implemented as a dynamic update technology -
>as the source XML changes (in this case the change would be caused from
>script triggered by the user input) XSL could create a minimal update of
the
>display (HTML).  I think this is where you would like us to be, but we just
>aren't there yet.

I know, and appreciate this. What I am saying is that in discussing how
forms should be handled in XSL we need to look beyond the server-based
response mechanisms of HTML and build in client side processing capability
as a basic feature. I don't expect this to be in place much before 2000, but
it is needed if we are to have XML-based Electronic Commerce systems for the
next century.


>I would be happy to look at your output to see what is going on, whether
>MSXSL is crashing or IE4.  If you use the command-line utility and feed the
>output into IE4, and it works, then the problem is within MSXSL.

I was planning to do some more tests and then send you a suitable fragment.
More on this next week.

>While I don't understand exactly what you are trying to do, this sounds
like
>you are complaining about MSXSL's lack of integration with the rest of the
>system - MSXML, DHTML, JavaScript, server-side stuff.  I heartily agree.
We
>have plans to make MSXSL easier to integrate into a web-application.  Thus
>each component can be targeted narrowly and optimized toward solving
>particular problems.

Great. I knew you guys had something in mind, I just wanted to make a clear
needs statement while we were starting to discuss forms on this list.

Martin Bryan


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