Appplication Specific Extensions

For example, the internal subset of a DTD based on the above standardized DTD could contain the following local redefinition for the %items; parameter entity:

Creating Message Instances

An XML/EDI electronic business message consists of a pointer to the document type definition, any definitions required in the internal subset of the DTD, and entries for each of the fields required for the message.

Validating Messages

XML/EDI messages can be validated by a validating XML document instance processor (known as an XML parsed to ensure they contain all required elements from the specified data set, and that the fields are in the required sequence. When the document is found to be valid the parser can generate a document tree that conforms to the rules laid down in the Document Object Model (DOM) specification that provides a standardized AN between XML parsers and browsers and other forms of program.

XML elements can be assigned attributes that point to processors that can undertake relevant data validity checks. This can be done either by associating notation processors with an element, or by associating an ECMAScript specification with the element as part of an XSL "action" associated with the specific element types used in specific contexts, or with particular attribute values.

Where the XML Style Language (XSL) is not being used (e.g. because the browser does not yet support it) the basic XML language allows user defined notation processors to be used to validate the contents of specific XML elements.

Enchanging Messages

Data captured in XML/EDI messages can be exchanged:

in the form of an XML file (which can be encoded in any way required, but would normally be transmitted using the UTF 8 encoding of the UCS 2 data set by default) interchanged using the HTTP protocol, or one of its derivatives (e.g. Secure HTTP)

in the form of a multipart Internet e mail message (MIME or Secure MIME encoded)

in the form of a zipped (or otherwise encoded) file transferred using the Internet File Transfer Protocol (FTP)

as a compressed (but not otherwise encrypted) set of extensions to an HTTP POST message that conforms to Internet's Common Gateway Interface (CGI) specification

in the form of an EDI message (created by processing the XML file at source using a special conversion program).

Where conversion into a known EDIFACT format is required the DTD can be extended to provide additional attributes that can guide the transformation process. For example, the following additional properties could be added to the list of attributes assigned to the EAN element:

Messages exchanged as XML/EDI files can be re validated on receipt by running them through an XML/EDI validating parser. Where messages have been converted into non XML files prior to transmission the conversion should be reversed to allow re validation of the received message.

During re valiclation any linked parts of messages should be retrieved to ensure that the full contents of the message have been checked. When re validation has been confirmed the Document Object Model created as part of the validation process can be used to create an auditable copy of the received message in a message store/ database.

Processing Messages

The way in which a received message would be processed would depend on which of the available methods for exchanging messages was chosen. If the message was received in a format that provided the XML/EDI message generated by the originator, the XML Style Language (XSL) can be used to associate different processes with individual element classes so that elements can be processed by one or more local processors.

XML/EDI message instances are specifically designed to make the selection of data fields and classes at the receiver as easy as possible. Each field starts with a "starttag" that clearly identifies the class (element type in SGML/XML parlance) of the following data or embedded subelement set, and specifies any non default properties to be associated with the data.

The end of each data element is clearly identified by an "end tag", which consists of the name of the element (class) preceded by a slash between a matched pair of outward pointing angle brackets. Fields that contain no data, and no embedded sub elements, (e.g. f ields that are only present to point to other data sources) have the slash indicating their end point immediately before the last angle bracket of the start tag rather than immediately after the first one of the end tag. (See the example for the element above.) Classes that contain sub classes of information have embedded elements between their start tag and end tag.

XSL allows sets of actions to be associated with particular XML elements. Actions can be defined in terms of values to be assigned to a set of data presentation attributes (styles), or in terms of a data processing script that users can define using a definescript object . XSL scripts are defined using the ECMAScript language used for exchanging Java programming modules.

Which actions are associated with which elements can be defined using XML element sets known as XSL rules. A simplified set of style rules allow presentation properties to be applied to element classes. Rules can be associated with elements that have been assigned a unique identifier (id) attribute or that have been assigned a particular value for a class attribute.

Sets of rules and actions can be defined in macros. Macros can be associated with style processing attributes associated with specific instances of an element. The default set of style properties defined in XSL can be extended using define style objects

The component parts of an XML Style Sheet can be:
defined in separate file(s) referenced using Internet URLs
associated with the definition of elements in the DTD
appended as a header to the document instance, or
associated with a specific instance of an element.

A typical XML/EDI XSL description will contain:

a element that contains ECMAScript definitions of the variables and functions required to process the document (in addition to the default function set provided by XSL)
a set of elements that provide named sets of predefined actions
a set of elements that define properties that are to be used to control style processing
a set of elements that contain within them: an elements that indicates which type of element the rule is to apply to, or
an element that identifies the unique identifier of the particular instance of an element the rule applies to, or an element that identifies which class of elements the rule is to apply to
an element that defines ancestors and descendants of the targeted element that must be present for the rule to apply (ancestors are dsfined by elements that surround the targeted element definition, descendants are defined by elements nested within the definition of the target element)
an element that identifies which attributes the selected element(s) must have before the rule applies
an element, which may have embedded within it a set of (argument) control elements, that indicates which macros are to be associated with the rule
a set of actions that must be processed/evaluated when the rule pattern is matched
a set of elements that show which presentation styles should be associated with particular element types/classes/instances.

Domain Name Search