Cover Pages: XML Daily Newslink: Monday, 21 January 2008

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:
BEA Systems, Inc. http://www.bea.com

Headlines

Unicode Transliteration Guidelines
Designing a Service Science Discipline with Discipline
Dispelling Myths Around ODF
Editor's Disposition of Comments Out (OOXML)
XBRL Versioning Specification Release 1.0
Lombardi Teamworks Conquers BPM with Superb Tools, Flexible Execution

Unicode Transliteration Guidelines
Staff, Unicode Consortium Report

Rick McGowan (Vice President, and IUC Chair, Unicode Consortium) announced the publication of the "Unicode Transliteration Guidelines" for the creation and use of CLDR transliterations. Transliteration is the general process of converting characters from one script to another, where the result is roughly phonetic for languages in the target script. For example, "Phobos" and "Deimos" are transliterations of Greek mythological [terms] into Latin letters, used to name the moons of Mars. There are several situations where this transliteration is especially useful, such as: (1) When a user views names that are entered in a world-wide database, it is extremely helpful to view and refer to the names in the user's native script. (2) When the user performs searching and indexing tasks, transliteration can retrieve information in a different script. (3) When a service engineer is sent a program dump that is filled with characters from foreign scripts, it is much easier to diagnose the problem when the text is transliterated and the service engineer can recognize the characters. Transliteration can also be used to convert unfamiliar letters within the same script, such as converting Icelandic THORN to 'th'. There are many systems for transliteration between languages: the same text can be transliterated in many different ways. CLDR provides for generic mappings from script to script (such as Cyrillic-Latin), and also language-specific variants (Russian-French, or Serbian-German). There can also be semi-generic mappings, such as Russian-Latin or Cyrillic-French. These can be referred to as script transliterations, language-specific transliterations, or script-language transliterations. Transliterations between Latin and other scripts are also called Romanizations... The Unicode CLDR provides key building blocks for software to support the world's languages. The Unicode Common Locale Data Repository (CLDR) is by far the largest and most extensive standard repository of locale data. This data is used by a wide spectrum of companies for their software internationalization and localization: adapting software to the conventions of different languages for such common software tasks as formatting of dates, times, time zones, numbers, and currency values; sorting text; choosing languages or countries by name; and many others.

Designing a Service Science Discipline with Discipline
Robert J. Glushko, IBM Systems Journal

This article has been published in the IBM Systems Journal special issue on "Service Science, Management, and Engineering" (Volume 47/ Number 1, 2008). The paper "relates our experiences at the University of California, Berkeley (UC Berkeley), designing a service science discipline. We wanted to design a discipline of service science in a principled and theoretically motivated way. We began our work by asking, 'What questions would a service science have to answer?' and from that we developed a new framework for understanding service science. This framework can be visualized as a matrix whose rows are stages in a service life cycle and whose columns are disciplines that can provide answers to the questions that span the life cycle. This matrix systematically organizes the issues and challenges of service science and enables us to compare our model of a service science discipline with other definitions and curricula. This analysis identified gaps, overlaps, and opportunities that shaped the design of our curriculum and in particular a new survey course that serves as the cornerstone of service science education at UC Berkeley... In contrast to service operations, the service-oriented architecture (SOA) perspective that underlies the design and deployment of Web-based services views the service life cycle in a nearly opposite way. SOA methodologies emphasize service design because precise, modular, specification-of-service interfaces and outputs are essential for reuse and interoperability. Instead of the highly variable experience of person-to-person services, service delivery in an SOA context is efficient and scalable. Service quality is objectively measured and often governed by service-level agreements that emphasize activities and measurements of the service provider. Our evaluation of the service life cycle from different perspectives forced us to confront the semantic challenge of harmonizing the conceptual and linguistic categories of different disciplines so that we could frame questions in ways that all of us could accept and understand..." [Note: Bob Glushko (Center for Document Engineering, UC Berkeley ) is a member of the OASIS Board of Directors.]

See also: the Robert J. Glushko bio

Dispelling Myths Around ODF
Erwin Tenhumberg, Erwin's StarOffice Tango

The 'In-Depth Research Overview' published by Burton Group on January 11, 2008 ("What's Up, .DOC? ODF, OOXML, and the Revolutionary Implications of XML in Productivity Applications") generated a large volume of response from commentators, including a response from the ODF Alliance ("Open Document Format Alliance Response to the Burton Group's Report"). In this connection, Erwin Tenhumberg's blog has been cited frequently. He writes: "Recent articles, reports and documents show that there are still a lot of misperceptions regarding ODF in the market. Apparently, many people are still not well informed about ODF even though they choose to write about ODF. Therefore, I thought it can't hurt trying to dispel a couple of myths around ODF... I hope the information [above] has helped to dispel a few myths around ODF and helps people reading articles, blog entries and analyst reports about ODF. From my point of view, ODF provides all an office suite user needs, and I'm sure that we will read a lot more great and encouraging news about ODF in 2008. Some of the "myths" discussed: ODF is controlled by Sun; ODF equals Open Source; ODF is very closely related to OpenOffice.org; Customer care about features, not formats; ODF is not being adopted; ODF has a very limited feature set; The Web makes ODF irrelevant; ODF is incompatible with Microsoft Office." Also in this connection, Carol Geyer (OASIS) reported that: "OASIS has been in contact with Burton Group concerning their report, "What's Up Doc?"-- as has IBM, ODF Alliance, Sun, and others. As a result, Burton analyst, Guy Creese, has published a blog post entitled, 'Some Counterpoint to Our ODF/OOXML Report'... Creese notes that Burton plans to update the report in the next quarter '... with an eye to (1) accepting or rebutting arguments made by others, (2) taking into account the result of the ISO vote, and (3) clarifying points that people misunderstood or misinterpreted."

See also: the Geyer posting

Editor's Disposition of Comments Out (OOXML)
Rick Jelliffe, O'Reilly News

The Editor's Disposition of Comments is quite an important document in the standards development process at ISO. After National Bodies submit their initial positions and comments on a late draft standard, the editor of the standard puts together a document to try to satisfy the various comments. Even though the Disposition of Comments document is not official, in the sense that anything in it is automatically accepted, it is usually the starting point for comment resolution, and, given that most comments are uncontroversial, is often the end-point too. Monday 14th Jan was the self-imposed deadline for the circulation of the IDS 29500 Editor's Disposition of comments. The comments and disposition documents have been leaked to the web, with no tears from anyone. Here [chart] is my rough characterization of them... The Editor (Rex Jaeschke on behalf of ECMA TC45) has accepted the lion's share. There is a small chunk of comments that are out of scope. There is a small chunk which the Editor has decided are issues for the maintenance phase, not the fast-track process: these are typically how comments like 'ODF has feature X, why doesn't OOXML support it?' There is another chunk of issues where the Editor disagrees with the substance of the comment, but wants to address the issue by adding clarifying or helpful text to the specification: for example, the issue of bitmasks is handled by giving examplars of how to handle them in XSD, RELAX NG, Schematron, DTLL and XSLT. And finally, another chunk where the Editor disagrees, and gives the rationale for the disagreement. Suggested resolutions for [four issues]: (1) Spreadsheet dates to go back before 1900, and can use ISO 8601 date format; (2) DEVMODE concerns printer-dependent data which may be binary: the editor suggests some minimal changes to say 'information' rather than 'data structure' and to show how the system would work with some future XML-based print structure (3) VML is being withdrawn from the places it is used in the specification, which now use DrawingML; (4) For Maths, the Editor recommends allowing alternative formats in particular recommending MathML: this is not to replace the OOXML Maths, but in the context of 'rehydration' which is where you want to round-trip through systems that don't support your full language...

See also: ECMA Comments note

XBRL Versioning Specification Release 1.0
Ignacio Hernandez-Ros (ed), XBRL Public Working Draft

Hugh Wallis (XBRL International, Director of Technical Standards) announced that the XBRL Versioning Working Group (VWG) has issued the first Public Working Draft for the Versioning Specification. The corresponding requirements document, conformance suite, and associated XBRL Infoset specification are also available online. The XBRL 2.1 specification defines the syntax and semantics of that syntax in order to define concepts, resources and relationships between those concepts and concepts and resources in a DTS (Discoverable Taxonomy Set). One of the most important benefits of the XBRL technology is that XBRL is a standard about how to define the report content. This means that new reporting requirements from regulators to regulated entities can always be incorporated using the same XBRL 2.1 technology without having to change the XBRL technology. In fact, when a new version of a DTS is released, the regulated entities will have to adapt existing mappings between internal data and the old concept definitions to the new concept definitions. It is expected that for all concepts with no significant changes the mapping rules can be adapted automatically... This specification defines the syntax and semantics of the versioning report. The versioning report represents the changes made to the concept definitions and resources that exist in two different DTSs. In the most common use case, the two DTSs will represent two consecutive versions of the same taxonomy. The most important motivation for the standardisation of a versioning report is the capacity to communicate changes in a DTS to taxonomy users. This capacity allows taxonomy users to identify and apply changes to internal systems. Some of the changes may be performed automatically by software using the versioning report and without human intervention and some other changes will always require human intervention... Because the versioning report is a communication tool, different taxonomy authors may want to communicate the same things in different ways. In this sense, the set of possible differences found between two DTSs can be ignored, considered separately or grouped together and documented separately in the versioning report. This specification does not impose any obligation to taxonomy authors to document changes in a specific way but rather provides a framework to standardize the way the changes are communicated so applications can consume that information for its purposes.

Lombardi Teamworks Conquers BPM with Superb Tools, Flexible Execution
James R. Borck, InfoWorld Product Review

The most well-rounded business process management system (BPMS) we've tested to date, Lombardi Software's Teamworks combines an execution and events monitoring engine with a close-knit IDE and tools for modeling and simulation analysis. With the inclusion of human-centric, collaborative workflow and services-based integration hooks, Teamworks can deliver near-seamless mapping, testing, and deployment to execute most any enterprise workflow. The Activity Wizard made creating rules, and defining human- and system-side interactions, much easier tasks. Solid introspection across Java and Web services—including a new UDDI tool—helped hasten discovery and development. Transports are well represented with SOAP and HTTP/REST-style invocations, as well as JMS and others. Support for BPMN intermediate events helps you flag exceptions and initiate compensation rollback procedures in the absence of more ACID-grade transaction management... Teamworks is rich in features and strong on tools, with additional perks such as a SharePoint add-on to build Web parts portlets, good subprocess exposure via Web services, a connector for Progress Sonic ESB (with hooks to Teamworks from Progress Actional in the works), and SAML support (one of the few BPM solutions to make the claim)... One may use popular browsers to complete process work or integrate with existing portals using JSR-168 or WSRP. On the downside, although Teamworks uses standard BPMN (Business Process Modeling Notation) for designs, its runtime engine is proprietary. This could limit execution portability compared to engines such as BEA/Fuego or Fiorano that handle BPEL natively.

See also: the features description


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

Headlines

Sponsors