Re: best way to generate form from xml+schema?

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