XML and Web Services In The News - 20 October 2006

Provided by OASIS | Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by BEA Systems, Inc.


 W3C Advances Delivery Context Interfaces (DCI) Specification to Candidate Recommendation
 SOA Reference Model Approved as an OASIS Standard
 Topic Maps, Knowledge, and OpenCyc
 Report on the Fifth European Networked Knowledge Organization Systems/Services (NKOS) Workshop
 OASIS CAM Version 1.1 XML Toolset
 Edwin Khodabakchian: Business Process Minded
 Learn to Cache Validation Metadata on the Client Side with JSON

W3C Advances Delivery Context Interfaces (DCI) Specification to Candidate Recommendation
Keith Waters, Rafah A. Hosn, et al, (eds), W3C Technical Report
Members of the Device Independence Working Group have released the "Delivery Context: Interfaces (DCI) Accessing Static and Dynamic Properties" specification as a Candidate Recommendation. The document defines platform and language neutral programing interfaces that provide Web applications access to a hierarchy of dynamic properties representing device capabilities, configurations, user preferences and environmental conditions such as remaining battery life, signal strength, ambient brightness, location, and display orientation. Delivery Context Interfaces (DCI) provides access methods for manipulating static and dynamic properties such that content can be adapted to a particular device context. These APIs are of particular relevance to multimodal interaction, where a variety of different modes can be present and active during a session. Many applications, particularly those that are device independent, are expected to function in heterogeneous environments with widely varying device capabilities. The device configuration, user preferences and environmental conditions can vary over time and applications need to be able to adapt accordingly. Within Web applications, a devices capabilities and operational environment can shape the input and output presented to the user via a browser. Once the available modes have been established, it is useful to distinguish between persistent (static) and transient (dynamic) properties. Static properties refers to data that remains constant for the session duration, for example specifying a users language preference for prompt playback, while dynamic properties refers to notifications and events during a session, for example generated through Global Positioning System (GPS) notifications [LIF] updating the location of a mobile device on a map rendered in a browser.
See also: W3C Device Independence Activity

SOA Reference Model Approved as an OASIS Standard
Rich Seeley, SearchWebServices.com
The votes are in and the OASIS "Reference Model for Service-Oriented Architecture 1.0" has been approved as a standard by OASIS, a spokesperson for the standards body confirmed Monday... The SOA-RM is intended to define the term clearly and technically for developers and architects. It might be hoped that the new standard will keep SOA terminology from being hijacked by software marketers eager to make sure their latest product release is buzz-word compliant whether or not it has anything to do with the service-oriented approach to application development. Abstract: "The Reference Model for Service Oriented Architecture is an abstract framework for understanding significant entities and relationships between them within a service-oriented environment, and for the development of consistent standards or specifications supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service oriented architectures or in training and explaining SOA. A reference model is not directly tied to any standards, technologies or other concrete implementation details. It does seek to provide a common semantics that can be used unambiguously across and between different implementations. While service-orientation may be a popular concept found in a broad variety of applications, this reference model focuses on the field of software architecture. The concepts and relationships described may apply to other 'service' environments; however, this specification makes no attempt to completely account for use outside of the software domain."
See also: the OASIS Standard

Topic Maps, Knowledge, and OpenCyc
Eliot Kimber, Blog
A recent comment about XTM (XML Topic Maps) reminded me that I ought to express a thought I've been having about topic maps for a long time. First, let me say that I've been involved with topic maps from the first moment the name was coined, way back at the CApH meeting in 1992. Our original goal was to define a simple application of HyTime that would put that very abstract and wide-ranging standard into a concrete application context that people could readily understand. The target use case was the generic representation of back-of-the-book indexes and thesauri. I think that topic maps are useful and attractive as far as they go: for the general business problem of managing metadata and associating it with data objects, it's well suited and well thought out... Why do I think that topic maps (and anything similar, such as RDF) is not suitable for knowledge representation? For the simple reason that knowledge representation is much more sophisticated and subtle than just topics with associations. That is, having topics with associations and a processor that can examine those is necessary but not sufficient for enabling true knowledge representation and true knowledge-based processing (that is, automatic processes that can do useful things with that knowledge, such as reliably categorize and index medical journal articles or make sense out of a vast pool of intercepted emails or analyze financial information to find market trends). I came to this understanding when I started trying to use the OpenCyc system to do reasoning on topic maps. The Cyc system is the brainchild of Doug Lenat, who had the idea that the only way to create a true artificial intelligence was to build up a massive database of "common sense", that is facts about everything in the world. Cyc has both an XML representation format for its data as well as a Python API, both of which made getting the topic maps into Cyc easy enough. However, at the time I tried this I was limited by the limitations in the OpenCyc database, which reflected only a fraction of the total Cyc database available in the commercial product. Doh! However, I notice that OpenCyc 1.0 claims to include the entire Cyc database. That would make a big difference. But more importantly, I quickly realized that the way Cyc represents the world is much much more sophisticated than a simple set of topics and associations.
See also: XML Topic Maps

Report on the Fifth European Networked Knowledge Organization Systems/Services (NKOS) Workshop
Traugott Koch, D-Lib Magazine
The Fifth NKOS Workshop took place on September 21 in Alicante, Spain, as part of ECDL 2006. The full-day workshop was attended by 30 colleagues from 18 countries on 4 continents. NKOS is a community of researchers, developers and practitioners seeking to enable knowledge organization systems (KOS) (e.g., classifications, gazetteers, lexical databases, ontologies, taxonomies and thesauri) as networked interactive terminology and knowledge organization services via the Internet. The first session of the workshop discussed the representation of and mapping between different KOS and the provision of terminology web services. Following up on earlier presentations at NKOS workshops, Margherita Sini talked about the FAO's work with OWL (Web Ontology Language) modelling of the multilingual AGROVOC thesaurus and continued steps towards an Agriculture Ontology Service. Advanced solutions are necessary in such a large scale KOS and varied service application. OWL and SKOS (Simple Knowledge Organisation System) seem to offer at least important parts of the knowledge representation required. Dennis Nicholson presented pilot web services solutions based on SRW (Search/Retrieve Web service) with the aim of making terminologies and mappings available, under development in the present phase III of the UK HILT project... Stella Dextre Clarke provided an update of the work being done to revise the UK BSI Standard on "Structured vocabularies for information retrieval", now focusing on the parts addressing multilingual vocabularies, mapping, and formats and protocols for interoperability.

OASIS CAM Version 1.1 XML Toolset
David RR Webber, Software Announcement
Members of the OASIS Content Assembly Mechanism (CAM) TC report the availability of a 'jCAM tool' compliant with the OASIS Content Assembly Mechanism Specification Version 1.1. [j]CAM is a simple XML rule-based validator and transformation toolset including Apache Maven pluggable extensions. It is intended for eBusiness use in formalizing the exchange of XML transactions between partners and establishing industry implementation guides for business transactions. You can use either lax or strict validation methods against your XML structures. You can quickly create CAM templates of your XML instances using the supplied generator options in the editor and the engine. These templates can then be easily scripted to provide business content checking using XPath based rule statements. CAM supports the use of context parameters to cope with partners differing roles and use cases. Sample templates are available for OASIS UBL SBS XML transactions. CAM is geared to providing rapid out-the-box handling of XML validation and then eBusiness integration into your backend environment using the provided 'Extension' mechanism. As a standards-based toolset CAM is also able to support use of JSR based tools such as DROOLS. The OASIS Content Assembly Mechanism (CAM) specification provides an open XML based system for using business rules to define, validate and compose specific business documents from generalized schema elements and structures. A CAM rule set and document assembly template defines the specific business context, content requirement, and transactional function of a document. A CAM template must be capable of consistently reproducing documents that can successfully carry out the specific transactional function that they were designed for. CAM also provides the foundation for creating industry libraries and dictionaries of schema elements and business document structures to support business process needs.
See also: OASIS Content Assembly Mechanism (CAM) TC

Business Process Minded
Edwin Khodabakchian, ACM Queue
This article is based upon Michael Vizard's Queuecast interview with Edwin Khodabakchian, vice president of product development at Oracle. EK: "When you look at SOA, the real pattern is about exposing services, and there are a set of standards for doing that: WSDL, XML Schema, and v arious types of security management in that area. Those standards are obviously important. Once you've exposed the services, you start thinking about how you are going to assemble them into end-to-end work flows. As you mentioned it, there is a business process execution language, which is actually quite a mature standard that evolved from the merger of X language, which was the standard Microsoft was working on, and WSFL, and has been submitted to OASIS. OASIS has been working on it for almost two years now. So BPEL, business process execution language, gives you the foundation for really starting to assemble a set of services into end-to-end processes. And those processes could be very short-lived. They could be long-lived. They could have business events into them. They could have compensation, parallel processing. So all the core semantics for executing business processes out of services is what's captured in the business process execution language. As you've mentioned, Version 2.0 is coming out this year, and what was really done within 2.0 was to take the 1.1 submission from the key vendors that submitted it and try to clean it up so that it became mature. So, 2.0 is out this year. On top of BPEL, there is a set of standards that are emerging that are simplifying the development of business processes. You have BPMN, which is the notation standard, which defined how you visualize a business process on a screen so that a business analyst can take a look at it — so it's all about visualizing business processes. You have BPEL for People, which is an extension provided to the core BPEL standard, that enables you to aggregate people as core activities of these end-to-end business processes that you're modeling. So there is a lot of activity going on on top of the BPEL foundation to really deliver things such as People Rules, Business Analyst Views, and over the next few years we should expect those layers to get as mature as what the BPEL standard is today.

Learn to Cache Validation Metadata on the Client Side with JSON
Bakul L. Patel, IBM developerWorks
Data validation is one of the most challenging and ever-changing parts of any enterprise Web application. Quite often validation metadata leaves JavaScript modules littered with server-side code. In this article, you'll learn an elegant way to cache metadata on the client side with the help of server code, which provides JSON-formatted (JavaScript Object Notation) stringified metadata. This approach also enables you to handle multivalue and multigroup attributes in a manner similar to Ajax. Each application targets some domain problem. And each domain has its own set of rules and regulations that put constraints on data. When an application applies those constraints on data, the constraints become validations. All applications need to validate the data that users enter. Today, applications generally use combinations of if-else statements to validate data. These statements contain validation data that developers either hard-code or put through server- side code. Generally, developers use server-side code to avoid small data changes that can lead to changes in JavaServer Pages (JSP). You can use JavaScript Object Notation (JSON) to group and cache metadata and use the JavaScript function to access that metadata to validate the user input. When you have metadata scattered over JavaScript, you can't control how much data the server evaluates and goes to the client. Instead, all server-side code pieces are evaluated and sent to the server. However, when you cache data using JSON, you have full control over how much metadata you send to the client because server-side code generates JSON-formatted metadata. This helps send only metadata to the client that corresponds to the user who will see or enter the data. You can also use JSON to cache data that the user inputs. Once the program caches the data, it erases the data fields rather than refreshing the screen, similar to Ajax. This way a user can enter another set of data for the same property.
See also: JSON.org web site

XML.org is an OASIS Information Channel sponsored by BEA Systems, Inc., IBM Corporation, Innodata Isogen, SAP AG and Sun Microsystems, Inc.

Use http://www.oasis-open.org/mlmanage to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml for the list archives.

Bottom Gear Image