Re: Some questions regarding XML/EDI

Jordan

Your message is still in my Inbox, so I probably skipped answering at the
time to await the XSL spec. Now that is availabel I better provide you with
a belated answer.

>> Hopefully the XML Style Language will go a long way to helping
convergence
>> in the area of processing XML components. However, there is a risk here:
no
>> one claims otherwise. At present we are actively working to reduce this
risk
>> to a bare minimum.
>
>If you had your way, ideally how would you want XSL
>implemented in a browser?

Ideally an XML browser should be able to:
a) Display a form to allow the capture of XML/EDI messages
b) Validate that entries made in the form are of an appropriate data type,
or conform to an agreeed set of permitted entries
c) Obtain information from a local database to complete form fields that
require information that is already available locally
d) Provide users with additional information on the rules for filling
specific fields on request
e) Display received XML/EDI messages in the language of the user, with
fields in the locally preferred order
f) Be able to validate the contents of received message fields using the
same rules as developed for b)
g) Be able to pass information received in certain fields to other processes
(e.g. updating local databases or triggering order processing sequences)
h) Be able to indicate to users which fields cannot be processed
automatically and require that they acknowledge that this information has
been processed manually (this is a form of workflow management associated
with received messages).

At present only e) is adequately handled by the first draft of the XSL
specification. Hopefully the XFDL protocol due for publication "early this
week" by XML.com will add some additional pieces to the jigsaw.

Martin Bryan


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list