Subject: Re: [xsl] best way to generate form from xml+schema? From: Graham Seaman <graham@xxxxxxxxx> Date: Tue, 16 Oct 2001 11:22:01 +0100 (BST) |
On Tue, 16 Oct 2001, Jeni Tennison wrote: > You can pass parameters with xsl:apply-templates as well as with > xsl:call-template. In fact, I think this is the best approach - apply > templates to work down the schema tree, but as you work down the tree > pass in the particular element from the instance tree that's relevant > at that particular point in the schema. It's very much in keeping > with the spirit of XSLT :) OK, I'll give it a try (once I've found your book!). I originally wanted to use xsl as far as possible, with perl just as a 'glue' language completely independent of the particular schema used. But I'm starting to wonder how practical that actually is (especially without the ability to use XML1.1 style variables). I've just started realising the problems in coming back in the reverse direction ie. once the form has been submitted, I need to take the incoming cgi parameters and match them against the schema to generate the new xml file. At the moment, the only idea I have for that is to give the cgi parameters names which reflect the xml structure (eg not 'email', but 'programItem:submitter:email'). Write the parameters to a temporary file. Then use a stylesheet heavily dependent on 'substring-after' functions to generate an xml file with expanded versions of the parameters (eg <programItem> <submitter> <email>a@xxx</email> </submitter> </programItem> Then read this into a second stylesheet which also reads in the schema to generate the full xml file. I'm assuming there's no way to do this more directly with only xsl1.0 variables... (eg. I can't pack the incoming parameters to a stylesheet into a variable and access them using 'name()' matched against the schema). It's starting to look like the number of file writes and reads may make this method too slow to be very practical compared with doing everything in Perl. Anyway, I'm sure I'll be back with some more concrete questions in a few days... > > I constructed a solution for precisely this problem for Chapter 10 of > Professional XSL from Wrox Press. You could probably come up with > something simpler in your situation, if you don't have to worry about > include/import/redefine in your schema, and particularly if you don't > have to worry about choices in the model groups, but it might be worth > taking a look at for some ideas. > I have one 'choice': maybe I can drop it if the problems it causes are too big... Thanks for the help! Graham XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] best way to generate form, Jeni Tennison | Thread | Re: [xsl] best way to generate form, Jeni Tennison |
[xsl] Saxon custom extensions probl, Gustaf Liljegren | Date | [xsl] Trying to match ..., Nicholas Waltham |
Month |