Re: Some XSL Questions

["Martin Bryan" <mtbryan@xxxxxxxxxxxxxx>]

Paul Grosso wrote:

>I should add that discussion on user requirements, design goals, and
general
>approach is not only appropriate, but very much welcome at this time.

Let me start by raising some user requirements regarding the use of  XML to
generate forms. These requirements are specified in the lights of the needs
of the XML/EDI Group.

To try to explain what I mean I have attempted to indicate how attributes in
the
document instance (which I would normally be expect to be specified using
default values) might be used to specify the types of operations required on
example form elements. I realise this is not how XSL proposes to work, but
have taken this approach to indicate that there is something special about
XML elements designed to capture rather than provide information. With
traditional XML elements style characteristics can be added as an
afterthought. With forms, the style in which the data is to be captured
normally has to be defined as part of the XML element, before the data
itself exists. Hence I have chosen to suggest an alternative mechanism for
identifying presentation style of elements designed to capture data.

While the examples given in the following statements of requirements are
specific to XML/EDI they are, I believe, likely to apply to many types of
applications. I therefore feel that as many of them as possible should be
part of the general XSL mechanism, though I accept that the XSL developers
may well choose to say that option X is too
difficult to generalize at present and must be handled specifically as part
of XML/EDI.

1. It should be possible to identify any XML element as one requiring user
input.
    E.g. <Date xsl:type="input 10"/> or
           <address xsl:type="textarea 40 5"><address>

2. It should be possible to validate the contents of any entered data at the
    client, ideally as soon as the user moves onto the next form field.
    E.g. <Date xsl:type="input 10" xsl:check="ISO8601Date">1999-02-29</Date>

3. It should be possible to transform entered values into transmittable
values at the
   client site, for example to allow users to enter dates in a locally
preferred form
   which the software will transform into a standardized form for
transmission:
   E.g. <Date xsl:type="input 30" xls:convert="ISO8601">
          27<sup>e</sup> Fev. '99</Date>

4. It should be possible to supplement (or replace) entered data with
displayable
    explanatory text. For example, on entering a customer reference number
(EAN)
    the system will display the full name and address of the customer.
    E.g. <CustomerNo xsl:type="input 8"

xsl:database="Customers">12345678</CustomerNo>
           will result a call to a local customer name/address database
           which will return the customer name and address for display on
the screen
           alongside the entered reference number.

5. It should be possible to obtain supplementary information from either
local or
    external sources. For example, if a product reference number (EAN) is
entered
    the system will look for product details on its local product database.
If it cannot
    find them there it will look one or more repositories on the network for
the
    relevant data
    E.g. <Product xsl:type="input 8" xsl:source="c:/database/products.csv
             http://www.ean.org/ucc";>25263462</Product>

6. It should be possible to store completed forms locally on submission for:
    a) purposes of auditing
    b) processing to update local databases, etc.

7. It should be possible to submit completed forms, in XML form, to
specified URLs
    and specify that receipt be acknowledged with a unique code generated in
    response to sending the form. E.g. combination of time and submission
number to
    uniquely identify transmitted message.

8. It should be possible to ask that form contents be converted into
separate format
    before transmission e.g. into CGI or EDI formats

9. It should be possible to use form elements with DSSSL-based flow objects
   when preparing data for display.





 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist