Re: Some questions regarding XML/EDI

Subject: Re: Some questions regarding XML/EDI
From: "Martin Bryan" <mtbryan@xxxxxxxxxxxxxx>
Date: Fri, 28 Aug 1998 08:06:51 +0100
Carlos Elkin Hernandez wrote

>>b) Validate that entries made in the form are of an appropriate data type,
or conform to an agreeed set of permitted entries

>How  could we achieve this, maybe using javascript to a local validation?

Ideally by using the more transportable ECMAScript language.

>>c) Obtain information from a local database to complete form fields that
require information that is already available locally

>Have you considered the security issues of browsers trying to gain access
to their Legacy system or files? If so, do you realise people trying to
adapt their local database tables to the valid ones?

Oh yes. The problem is that there is a vast amount of information associated
with EDI messages that has no security implications but which needs to be
kept client side to reduce communications costs and time. For example,
mapping of EAN numbers to product names and company addresses, etc. It is
better to set up secure caches of referencable information at the client
than to expect the data to be picked up by referencing a remote site using
yet another HTTP transaction.

>>e) Display received XML/EDI messages in the language of the user, with
fields in the locally preferred order

>I would like to see it working. Where would be the Mapping rules running?

In the XSL specification of presentation for that type of message held at
the client. (This is the beauty of being able to decouple presentation from
information semantics that XML and XSL provide us with.

>>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
(e.g. updating local databases or triggering order processing sequences)

>Same comment that c)

I presume this applies to g) but not to f), where my comments for b) apply.
There is a different level of security involved here, but in this case it is
normally purely an in-house security function. You are not changing anything
in the message, simply providing a mechanism whereby information within a
message can be passed to relevant applications. This has no more security
implications than any other API.

Marin Bryan

 XSL-List info and archive:

Current Thread