Subject: Re: SGML and Forms From: "Martin Bryan" <mtbryan@xxxxxxxxxxxxxx> Date: Sat, 7 Mar 1998 10:18:49 -0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: SGML and Forms, Jonathan Marsh | Thread | select v. select-elements, Frank Boumphrey |
Re: Style vs. transformation, Brad McCormick, Ed.D | Date | Re: Style vs. transformation, Paul Prescod |
Month |