Cover Pages: XML Daily Newslink: Tuesday, 17 July 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:
IBM Corporation http://www.ibm.com

Headlines

Efficient XML Interchange (EXI) Format 1.0
GCN Editor's Desk: Open Progress
IETF Publishes RFCs for Abstract Syntax Notation X (ASN.X)
W3C Advances XHTML Basic Version 1.1 to Candidate Recommendation
Open Source Semantic Desktop Is Coming
Open Source JBoss Rules Gains Speed
XQuery and Data Abstraction
Why the Open Source Community Should Support an ISO Office Open XML Standard

Efficient XML Interchange (EXI) Format 1.0
John Schneider and Takuki Kamiya (eds), W3C Technical Report

W3C announced that the Efficient XML Interchange Working Group has published the First Public Working Draft for "Efficient XML Interchange (EXI) Format 1.0." XML has been enormously successful as a markup language for documents and data, but is not an optimal format for all purposes. The XML Binary Characterization Working Group established a set of use cases for which XML employment may be problematic. The Efficient XML Interchange Working Group was chartered to define an alternative encoding of the XML Information Set that addresses at least the minimum requirements identified by the XML Binary Characterization Working Group. The Efficient XML Interchange (EXI) format is a very compact, high performance XML representation that was designed to work well for a broad range of applications. It simultaneously improves performance and significantly reduces bandwidth requirements without compromising efficient use of other resources such as battery life, code size, processing power, and memory. EXI uses a grammar-driven approach that achieves very efficient encodings using a straightforward encoding algorithm and a small set of data types. Consequently, EXI processors are relatively simple and can be implemented on devices with limited capacity. EXI is schema "informed", meaning that it can utilize available schema information to improve compactness and performance, but does not depend on accurate, complete or current schemas to work. It supports arbitrary schema extensions and deviations and also works very effectively with partial schemas or in the absence of any schema. The format itself also does not depend on any particular schema language, or format, for schema information. A program module called an EXI processor, whether it is part of a software or a hardware, is used by application programs to encode their structured data into EXI streams and/or to decode EXI streams to make the structured data accessible to them.

GCN Editor's Desk: Open Progress
Wyatt Kash, Government Computer News Editor's Desk

The news earlier this month that Massachusetts was likely to approve Microsoft's Office Open XML (OOXML) format as an alternative for creating state documents set off a fresh firestorm of debate over proprietary versus open document formats. The proposal, included in a new draft of Massachusetts' enterprise technical reference model, effectively reverses a controversial stand the commonwealth took two years ago when it announced plans to ban the use of proprietary formats in creating government documents. At the time, the announcement by then-chief information officer Peter Quinn was seen in software circles as revolutionary—and something of a victory for advocates of the Open Document Format (OOF). It certainly played well with those who railed against Microsoft's ubiquitous grip on office documents. So it's not surprising that some would see this latest development as the political equivalent of Massachusetts extending import rights to the British East India Co., the company whose favored status granted by the British Parliament led to the Boston Tea Party... In the end, although many may complain about OOXML and Massachusetts' course reversal, Quinn's Technology Tea Party deserves credit for speeding progress toward liberation of data from the documents in which it resides.

IETF Publishes RFCs for Abstract Syntax Notation X (ASN.X)
Steven Legg (et al., eds), IETF RFC

Announcements from the IETF RFC Editor report the availability of five related Request for Comment specifications in online RFC libraries. [1] RFC 4912 "Abstract Syntax Notation X (ASN.X)" defines a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. [2] RFC 4910 "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)" defines rules that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type and also defines a restriction of RXER, called the Canonical Robust XML Encoding Rules (CRXER), which does produce a single unique encoding for an ASN.1 value. [3] RFC 4911 "Encoding Instructions for the Robust XML Encoding Rules (RXER)" defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. [4] RFC 4913 "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)" specifies the ASN.X representation for EncodingInstructionAssignmentList and EncodingInstruction as they are defined for the Generic String Encoding Rules (GSER). [5] RFC 4914 "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)" specifies the ASN.X representation of encoding instructions for XER.

W3C Advances XHTML Basic Version 1.1 to Candidate Recommendation
Mark Baker, Masayasu Ishikawa, Shinichi Matsui (et al., eds), W3C CR

W3C has announced the publication of the "XHTML Basic 1.1" specification. XHTML Basic Version 1.1 is intended to be the convergence of the XHTML Basic 1.0 W3C Recommendation for mobile devices, released in coordination with the WAP Forum in 2000, and the Open Mobile Alliance (OMA) XHTML Mobile profile. Implementation feedback is welcome through 31-August-2007. The XHTML Basic document type includes the minimal set of modules required to be an XHTML host language document type, and in addition it includes images, forms, basic tables, and object support. It is designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes. The document type is rich enough for content authoring. XHTML Basic is designed as a common base that may be extended. The goal of XHTML Basic is to serve as a common language supported by various kinds of user agents. This revision, 1.1, supercedes version 1.0 as defined in the W3C Recommendation of 19-December-2000. In this revision, several new features have been incorporated into the language in order to better serve the small-device community that is this language's major user: (1) XHTML Forms; (2) Intrinsic Events; (3) The value attribute for the 'li' element; (4) The target attribute; (5) The style element; (6) The style attribute; (7) XHTML Presentation module; (8) The inputmode attribute. The document type definition is implemented using XHTML modules as defined in "XHTML Modularization".

See also: the W3C news item

Open Source Semantic Desktop Is Coming
Sean Michael Kerner, InternetNews.com

PC users have volumes of information saved on their computers, most of it disconnected and disparate save for a basic directory system. The answer to connecting all the information into a local semantic Web of information is closer than you might think. Thanks to the open source NEPOMUK (Networked Environment for Personalized, Ontology-based Management of Unified Knowledge) effort, the Semantic Desktop isn't a dream; it's an emerging reality and will be here with the upcoming release of KDE 4 for the Linux desktop. Mandriva is an active participant in the NEPOMUK effort along with HP, IBM, SAP and others. Among the ways that Mandriva expects to take advantage of the Semantic Desktop include a community help desk system and a P2P framework for the exchange of data and information. The Semantic Desktop is more power than just using Google Desktop search [since] existing desktop search tools are limited to full text indexing. From the Wiki: "NEPOMUK realizes an open-source framework which allows integration of thirdparty components via pluggable adaptors. The core components and approaches will be actively promoted in open development communities in order to reach an early large-scale uptake and feedback. Relevant interfaces and data structures will be submitted to the appropriate standardization committees like OASIS or W3C. The technical work packages for the personal semantic desktop comprise tools for knowledge articulation and visualization, the interfaces and data structures of the personal semantic web, and integration of personal work process support."

See also: the Wiki

Open Source JBoss Rules Gains Speed
Paul Krill, InfoWorld

JBoss has announced a faster version of JBoss Rules, the company's open source business rules engine. Gains in speed in version 4.0 have resulted in rules processing in seconds as opposed to minutes, according to Burr Sutter, technical product manager for JBoss. Speed has been increased by new "sequentiality" methods, which do not assume the rules change all the time. The product is 40 percent faster than before. Based on the JBoss Drools Project, JBoss Rules is used to set rules within a business process. It can be deployed for functions such as establishing computational business logic associated with an application. Examples would be a pricing engine or a routing node. An AJAX-enabled Web console in version 4.0 extends Rules to nonprogrammers. JBoss Rules is being integrated with the JBoss ESB (Enterprise Service Bus), in which the rules engine can examine the content of a message, such as an invoice, and make decisions on where to send the message. The ESB handles message flow while Rules serves as a 'traffic cop' working in conjunction with the ESB. JBoss Rules 4.0 is also described as being Hibernate-ready; that is, it can function with JBoss' Hibernate object-relational mapping software, which converts relational database rows into Java objects. A business rule could be built that, for example, pulls customer names directly from the database. Website description: "JBoss Rules is an open source and standards-based business rules engine for easy business policy access, change, and management. JBoss Rules is a fast, highly efficient rules engine that makes it easy for a business analyst or auditor to view business rules, as they are encoded in your IT application infrastructure, to verify that the encoded rules indeed implement the documented business policies. JBoss Rules also supports a variety of language and decision table inputs, making it easy to quickly modify business policies to respond to opportunities and competitive threats."

See also: the web site

XQuery and Data Abstraction
Kurt Cagle, XML.com

An XML database differs from a relational one in a few key respects: (1) Semi-structured data: Because XML may have multiple possible options, modelling XML in a relational database can prove to be an expensive and ultimately self-defeating proposition, especially for information like a web page that tends to be very unstructured; (2) Externally defined schemas: An XML document does not necessarily need a formal schema, whereas such a schema is an implicit part of a relational database. (3) Tables, and hence all fields, within a given database occupy the same namespace; this assumption is generally not true with regards to XML documents, where a given instance may potentially have dozens of namespaces associated with various elements and attributes. (4) Weakness of keys: A significant amount of the power in a relational database comes from the use of keys, primary and foreign, in order to bind various sets of records together. (5) Element multiplicity: In an RDBMS, fields are unique within a given table; there can only be one field with that name in the table itself. In an XML document, a given set of child elements may in fact all have the same name, some may have the same name, or none of them may have the same name. In general, XML databases get around these limitations by using the names of each element in a given document as table names with relationships kept as pointers to the various child, attribute, text, and, perhaps, parent nodes. By indexing each element with an eye toward its text content, this makes it possible to perform searches based on proximity between terms and to then retrieve the nodes that are the nearest ancestor to the node containing the text. When I started working with XQuery, I was initially skeptical about it. Recently, as I see the implications that are opened up by the modularization of the language, the emergence of XQuery aware data repositories, and the shift towards rich client applications that are increasingly XML-centered, I'll admit that I was wrong in my initial assessments. XQuery is an important technology, and it will very likely have a huge impact upon the way that applications are built, especially in distributed environments.

Why the Open Source Community Should Support an ISO Office Open XML Standard
Rick Jelliffe, O'Reilly Opinion

There have long been two different camps in the Open Source movement: those who think that it is important to have independent APIs and those who think that it is important to have Open Source clones of the most important proprietary APIs. This latter group is of course associated with Novel and the Mono effort is a good example: on their history, I don't think they have much problem with Open XML going through ISO... I think the reasons for supporting Open XML at ISO become a lot clearer if we take a fairly hard-headed view of what is possible. Which is perhaps a nicer way of saying that I think some of the anti-Open XML case has been built on naively faulty assumptions about the miraculous power of ODF to disrupt Microsoft... In my jaded view, ODF will not make Office go away, ISO ODF will not make Ecma Open XML go away, and ISO Open XML will not make ISO ODF go away. So I see no downside in Open XML becoming an ISO standard: it ropes Microsoft into a more open development process, it forces them to document their formats to a degree they have not been accustomed to (indeed, the most satisfactory aspect of the process at ISO has been the amount of attention and review that Open XML has been given), and it gives us in the standards movement the thing that we have been calling for for decades.


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

Headlines

Sponsors