Lists Home |
Date Index |
- From: Richard Light <firstname.lastname@example.org>
- To: email@example.com
- Date: Mon, 2 Jun 1997 11:12:30 +0100
In message <199706011613.MAA10043@smtp2.erols.com>, Peat
>Advantages of including Electronic Data Interchange (EDI)
>entities with eXtensible Markup Language (XML)
>What could the EDI entities look like?
>The general format of the transaction would be described in HTML. The EDI
>segments and elements could go something like this...
Another approach (which is compatible with that used for the XML linking
specification) is to have attributes which identify certain elements as
holding EDI information. That way, the EDI information is explicitly
labelled, and an XML processor can be asked to return it to an
application using standard API calls.
This approach means that the EDI information forms part of the logical
structure of the XML document, rather than being a CDATA 'implant'. It
also means that users can define their own element types to hold EDI
information, so long as they label them with the agreed attributes.
Furthermore, it allows them to use XML's built-in validation facilities
to check for structurally valid input, e.g.:
in the DTD:
<!ELEMENT DUNS-GROUP (N101, N102?, N103, N104) >
<!ATTLIST DUNS-GROUP EDI-TYPE CDATA #FIXED "ANALYSED DUNS NUMBER">
<!ELEMENT N101 (#PCDATA) >
<!ATTLIST N101 EDI-TYPE CDATA #FIXED "DUNS NUMBER PREFIX">
in the document:
Note that the EDI-TYPE information is declared once and once only, in
the DTD, and does not add to the markup overhead in the actual document.
SGML and Museum Information Consultancy
3 Midfields Walk
West Sussex RH15 8JA
tel. (44) 1444 232067
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)