The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: November 22, 2000
XML Transition Network Definition (XTND)

[November 22, 2000] In November 2000, a two-part submission from eBusiness Technologies, Inc. was acknowledged by W3C for (1) XML Transition Network Definition (XTND) and (2) XEXPR - A Scripting Language for XML.

The specification XTND - XML Transition Network Definition provides a generic DTD which uses XEXPR. Description: "In XML-based standards there often arises the need for two components: (1) A component for describing, declaratively, a set of states, and transitions between them: for example, when describing business processes, protocols, or decision trees. (2) A component allowing logic to be embedded into the XML. This submission is made up of two parts: XTND and XEXPR. XTND is a generic DTD that can be used for describing transition networks, and their interaction with the outside world. XEXPR is a scripting language that uses XML syntax, and hence is designed to be embedded in XML. XTND uses XEXPR. eBT is submitting these two specifications to the W3C in the hope that they will be incorporated into future specifications that need such functionality." The XTND part of the specification (XML Transition Network Definition), published as W3C Note 21-November-2000, provides formal constructs for encoding states and transitions in events in processes. Description: "In many systems, transition networks are used to describe a set of states and the transitions that are possible between them. Common examples are such things as ATM control flows, editorial review processes, and definitions of protocol states. Typically, each of these transition networks has its own specific data format, and it's own specific editing tool. Given the rapid transition to pervasive networking, and to application integration and interchange, a standard format for transition networks is desirable. This document defines such an interchange format, defined in XML: the interchange language for the Internet... Loosely speaking, a transition network is a set of states and the transitions between them. They are good at capturing the notion of process. For example: (1) Control processes such as those in a digitally controlled heating system. (2) Processes controlling manufacture or design. (3) Workflow processes such as those found in product data management software. They are also useful in modeling the behavior of systems and can be used in object-oriented analysis to create formal models of object interaction and larger system behavior. Transition networks are closely related to finite state machines (FSM), and to data flow diagrams(DFD), but they are augmented with the following capabilities: (1) Transition networks are not limited to "accepting or rejecting their input". Transition networks may execute actions or fire off events during transitions. (2) Transition networks can interact with other objects, thereby affecting change in the transition network (or in other networks). (3) Transitions in transition networks can be controlled by guard conditions that prohibit or allow the transition to be followed. (4) These guard conditions can be dependent on any predicate involving objects from within the environment of the transition network. As such, transition networks can be used to describe far more complex interactions or processes than either FSMs or DFDs allow... Transition networks form a graph, and XML is hierarchical, so there would appear to be some discord between the two models. This is not the case if a transition network is seen as a set of states, and a set of transitions: these sets can be easily marked up in XML. Following the practice of natural design leads to a fairly natural mapping from this view of a transition network to its XML representation."

The W3C staff comment says of the submission, in part: "It is common to combine the declarative potential of XML with imperative scripting languages such as ECMAScript. The submission defines a new scripting language (XEXPR) which is itself expressed directly in XML. The language takes a functional approach and avoids the need for further parsing machinery as would be needed for a syntax featuring infix operators. The submission demonstrates the use of XML for defining a functional scripting language and for representing finite state transition networks. This may prove to be of interest to future W3C work on dialogs for human-computer interaction, and more generally as a component for a Web application framework. Current W3C work on voice browsers is taking a different approach, using a form filling metaphor for representing dialogs, with a focus on easy authoring for voice applications. This work is drawing upon rich experience with earlier markup languages for voice interaction, and it is unclear whether the more abstract approach presented in the submission is relevant. W3C's work on forms is using XML Schema as the basis for the modelling data, with the addition of dynamic integrity constraints that act over multiple fields. For example, the total value of an order can be defined in terms of a computation over the values of other fields such as unit prices, quantities, discounts, and tax and shipping costs. Such computations can be conveniently represented as expressions that evaluate to typed values. The focus is on a simple side-effect free representation of constraints, based upon the type system defined by XML Schema and the use of XPath for addressing form data. The XML scripting language proposed in the submission could be of interest to the XForms working group, but may prove to be too complicated, for the restricted requirements for forms. XForms is expected to have to interoperate with popular scripting languages such as ECMAScript. This avoids the need for the constraint language to evolve into a general purpose scripting language."

XEXPR was published as a separate NOTE: XEXPR - A Scripting Language for XML. Reference: W3C Note 21 November 2000, by Gavin Thomas Nicol (Chief Scientist, eBusiness Technologies, Inc.). Document abstract: "In many applications of XML, there is a requirement for using XML in conjunction with a scripting language. Many times, this results in a scripting language such as JavaScript being bound within the XML content (like the <script> tag). XEXPR is a scripting language that uses XML as its primary syntax, making it easily embeddable in an XML document. In addition, XEXPR takes a functional approach, and hence maps well onto the syntax of XML... The grammar for the XEPR language - a deliberate pun on SEXPR, is defined. The grammar cannot be expressed completely in a DTD, because DTDs assume a fixed vocabulary (fixed set of tags), and the XEXPR language allows arbitrary definitions (arbitrary tag definitions) to occur. From a practical perspective this means that a document with arbitrary XEXPRs embedded within it cannot be validated against a DTD unless the DTD is extended to include definitions of all the tags found in the expressions in the document."

References:


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/xtnd.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org