This example shows how a separate SCHEMA can also be provided to further normalize
the data prior to binding. In this example the customer data
is more structured. The <NAME> now consists of <FIRST>, <MIDDLE>,
and <LAST> parts that are specified in random order. The <DATE>
is now stored as separate components: <DAY>, <MONTH>, and <YEAR>.
,
//
The problem with this extra structure is that the schema generator
now considers the <NAME> and <DATE> nodes as ROWSETS
when they are never really going to be repeated. Having them become
ROWSETS makes it much more effort to bind to the sub-fields.
To avoid this extra work, you can hand-tune the schema that is
generated by removing the unwanted ROWSETS and then providing this
in a SCHEMA <PARAM> on the <APPLET> tag as follows: