Cover Pages: XML Daily Newslink: Monday, 09 April 2007

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Primeton http://www.primeton.com

Headlines

Design an SOA Solution Using a Reference Architecture
Public Review Draft for OASIS EDXL-RM Version 1.0
Haley 6.0 Extends Business Rules to Business People
XSL Transformations
Last Call for EMMA: Extensible MultiModal Annotation Markup Language
ebXML Registry Profile for Web Ontology Language (OWL) Version 1.5

Design an SOA Solution Using a Reference Architecture
Ali Arsanjani (et al), IBM developerWorks

In recent years, the decoupling of interface from implementation at the programming level has become a popular architectural approach because such decoupling facilitates the creation of complex systems required by today's business applications. According to this approach, the interface of a service consumed by a service consumer is loosely coupled with its implementation by a service provider and the implementation is decoupled from its binding. This style has become the key characteristic of Service-Oriented Architecture; that is, rather than the implementations of components being exposed and known, only the services provided are published and consumers are insulated from the details of the underlying implementation by a provider or broker. SOA allows business and IT convergence through agreement on a set of business-aligned IT services that collectively support an organization's business processes and goals. Not only does it provide flexible, decoupled functionality that can be reused, but it also provides the mechanisms to externalize variations of quality of service; for example, in declarative specifications such as WS-Policy and related standards. In this article you explore an SOA reference architecture, which provides roadmaps and guidelines for architectural, design, and implementation decisions. Additionally, it provides patterns and insights for integrating these aspects. As part of that reference architecture, reusable assets are being created to enable end-to-end, SOA-based business solutions that cover enterprise modeling, business process modeling, service modeling, as well as integration and management of business applications. The long-term goal of the SOA solution stack is to provide templates and guidelines to help architects facilitate and automate the process of modeling and documenting the architectural layers, building blocks, options, product mappings, and architectural and design decisions that contribute to the creation of an SOA.

Public Review Draft for OASIS EDXL-RM Version 1.0
Members, OASIS Emergency Management TC Draft

As detailed in the EDXL_DE Specification, the goal of the EDXL project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL will accomplish this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession jor governmental jurisdiction is involved. This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding. The primary purpose of the Emergency Data Exchange Language Resource Messaging (EDXL_RM) specification is to provide a set of standard formats for XML emergency messages. These Resource Messages are specifically designed as payloads of Emergency Data Exchange Language Distribution Element-(EDXL_DE)-routed messages. Together EDXL_DE and EDXL_RM are intended to expedite all activities associated with resources needed to respond and adapt to emergency incidents. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/ recipient IDs. The Resource Message is constrained to the set of Resource Message Types contained in this specification. The Resource Message is intended to be the payload or one of the payloads of the Distribution Element which contains it.

See also: the OASIS TC

Haley 6.0 Extends Business Rules to Business People
Steven Nunez, InfoWorld

Haley Systems today introduced version 6.0 of the Haley Business Rules Suite, a BRMS that boasts both a strong pedigree and some unique features. The company was founded in 1989 by Paul Haley, the ex-Inference chief scientist who helped develop ART, one of the first commercially successful rule engines. The Haley 6.0 BRMS suite consists of three components: Haley Authority, a rule authoring environment; Haley Rules Server, a rule execution engine; and Haley Collaboration Server, a Web application that enables distributed rule management and authoring. HaleyAuthority is the thick-client, Java-based, desktop application for creating and maintaining rule ontologies; from here you can import existing business object models, configure rule services as part of an SOA, or build a new model from scratch. This is where all the heavy lifting is done in creating an environment whereby business analysts can author and maintain business rules. The Haley approach is almost like typing English sentences. This NLP (Natural Language Processing) technology is used consistently throughout the product set, and it's available in all authoring environments, even the Excel plug-in. This is a fascinating technology, with applications beyond mainstream BRMS. I can think of some interesting uses in the Semantic Web, for example. Building upon the NLP framework, Haley offers knowledge packs for two industry verticals, mortgage lending and insurance. Based on the MISMO and ACCORD XML standards respectively, these knowledge packs offer pre-built language customizations, meaning that all of the industry standard phrases and vocabulary are there from the start. All that remains is for a business analyst to start entering rules. I was impressed by the fact that the system offers the same interfaces to external applications as it uses internally. The same goes for Haley's XML: everything in the system communicates using KML (Knowledge Modeling Language).

XSL Transformations
Zeki Bayram and Ruhsan Onder, DDJ

Sending code over the Internet to be executed on client web browsers represents one more degree of freedom than what is currently available, which is that the language available in the browsers is fixed, and only programs written in that language, and data to be used by that program, are sent to the browser. The possibility of bundling together the language processor with the program and data opens up tremendous opportunities, allowing special purpose languages to be developed and used without requiring the end users to install additional components to their web browser. This also largely eliminates compatibility problems stemming from the unstandardized nature of scripting (and other) languages built into web browsers currently in use. XIM is an XML-based programming language with imperative control features, such as assignment and loops, and an interpreter written in XSLT. XIM programs can thus be packaged with an XIM processor (as an XSLT stylesheet) and sent to the client for execution. In this article, we define the language and examine its operational semantics implementation in XSLT. To show the usefulness of packaging code with its execution engine, we present a web application that accepts user choices, gets the parameters for the requested operation, generates an XIM program that does the computation, and sends the program—together with its interpreter—to the client for execution. The implications of this approach are significant. In principle, you don't need to be restricted to existing programming languages on the client side. Nor do you need to make assumptions about the availability of certain environments on the client side—other than that of the XSLT processor, which is already supported in all mainline web browsers. This gives you the freedom of choosing any programming language, provided its processor can be packaged and sent to the client with it.

Last Call for EMMA: Extensible MultiModal Annotation Markup Language
Michael Johnston (et al., eds.), W3C Technical Report

W3C's Multimodal Interaction Working Group has published a Last Call Working Draft for "EMMA: Extensible MultiModal Annotation Markup Language." The MMI working group aims to develop specifications to enable access to the Web using multimodal interaction. The EMMA document is part of a set of specifications for multimodal systems, and provides details of an XML markup language for containing and annotating the interpretation of user input. Examples of interpretation of user input are a transcription into words of a raw signal, for instance derived from speech, pen or keystroke input, a set of attribute/value pairs describing their meaning, or a set of attribute/value pairs describing a gesture. The interpretation of the user's input is expected to be generated by signal interpretation processes, such as speech and ink recognition, semantic interpreters, and other types of processors for use by components that act on the user's inputs such as interaction managers. Components that generate EMMA markup include: (1) Speech recognizers; (2) Handwriting recognizers; (3) Natural language understanding engines; (4) Other input media interpreters (e.g. DTMF, pointing, keyboard); (5) Multimodal integration component. Components that use EMMA include the interaction manager and multimodal integration component. Although not a primary goal of EMMA, a platform may also choose to use this general format as the basis of a general semantic result that is carried along and filled out during each stage of processing. In addition, future systems may also potentially make use of this markup to convey abstract semantic content to be rendered into natural language by a natural language generation component. This Last Call working draft also incorporates numerous editorial revisions and clarifications made in response to detailed feedback from the Internationalization working group, the Web Accessibility Initiative, the Voice Browser working group, and the Smartweb consortium. These changes include marking of normative versus informative material and use of the key words as described in RFC 2119 to clarify the status of statements in the specification.

ebXML Registry Profile for Web Ontology Language (OWL) Version 1.5
Asuman Dogac (ed), OASIS Approved Committee Specification

OASIS announced that members of the OASIS ebXML Registry Technical Committee have approved a September 2006 Committee Draft version of "ebXML Registry Profile for Web Ontology Language (OWL) Version 1.5" as a new Committee Specification. The document defines the ebXML Registry profile for publishing, management, discovery and reuse of OWL Lite Ontologies. The ebXML Registry holds the metadata for the RegistryObjects and the documents pointed at by the RegistryObjects reside in an ebXML repository. The basic semantic mechanisms of ebXML Registry are classification hierarchies (ClassificationScheme) consisting of ClassificationNodes and the Association Types among RegistryObjects. Furthermore, RegistryObjects can be assigned properties through a slot mechanism and RegistryObjects can be classified using instances of Classification, ClassificationScheme and ClassificationNodes. Given these constructs, considerable amount of semantics can be defined in the registry. However, currently semantics is becoming a much broader issue than it used to be since several application domains are making use of ontologies to add knowledge to their data and applications. As a part of this initiative, W3C's Web Ontology Working Group defined Web Ontology Language (OWL). Naturally, there is lot to be gained from using a standard ontology definition language, like OWL, to express semantics in ebXML registries. This document normatively defines the ebXML Registry profile for Web Ontology Language (OWL) Lite. More specifically, this document normatively specifies how OWL Lite constructs should be represented by ebXML RIM constructs without causing any changes in the core ebXML Registry specifications. Furthermore, this document normatively specifies the code to process some of the OWL semantics through parameterized stored procedures that should be made available from the ebXML Registry. Although this Profile is related to ebXML Registry specifications and not to any particular implementation, in order to be able to give concrete examples, the freebXML Registry implementation is used.

See also: the OASIS TC


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors