Cover Pages: XML Daily Newslink: Friday, 15 February 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:
Sun Microsystems, Inc. http://sun.com

Headlines

WLS 10.3 Tech Preview Supports Service Component Architecture (SCA)
SEC Financial Explorer Supports XBRL Interactive Data
W3C Last Call Working Draft: CSS Namespaces Module
OASIS TC Publishes Code List Representation (Genericode) Version 1.0
XML 1.0 (Fifth Edition)
OASIS Members Submit Charter for ebXML Core (ebCore) Technical Committee
SourceForge: Office Binary (doc, xls, ppt) Translator to Open XML Project

WLS 10.3 Tech Preview Supports Service Component Architecture (SCA)
Vijay Mandava, Blog

WebLogic 10.3 Tech preview now supports Service Component Architecture (SCA) runtime. The SCA specification has two main parts: implementation of service components (which can be done in any language) and the assembly model which is the linking of components through wiring (which is done through XML files). Every component technology (Spring, POJO, EJB etc) that wants to participate in the SCA framework should support SCA metadata. The SCA specification defines language bindings for each of the technologies. In my opinion, SCA is the next evolution of building interoperable distributed systems. The claim to fame for SOAP based web services is that it provided a programming model where clients do not care as to which programming language the service is implemented. The client can be written in any language that has a SOAP binding. The only restriction on the client is that it has to use the SOAP API. Thus by service enabling your existing business services and modifying your legacy clients to speak SOAP, web services have made enterprise integration easier compared to yester years. Now SCA takes this interoperability to the next level, where now your clients can stay as is and do not have to use the same transport as the service. All the client knows is that it is a remotable service. Let us say you have a Java client that was talking to an EJB. Now this EJB has been converted into a web service. In this case, the Java client does not have to change to use SOAP API. Instead it can still use its EJB client code because the web service (which is an SCA component) can be decorated with an EJB binding. Thus the service can be implemented in one technology such as Spring, POJO, EJB, web service or BPEL and it can be decorated with a different binding (Spring, POJO, EJB, web services etc) to support different clients. By including the SCA runtime on WLS, customers can take advantage of the RASP functionality provided by WLS for the deployed SCA components. The infrastructural capabilities such as security, transactions, reliable messaging that are to be handled declaratively through policies under the SCA specification can all be provided by WLS.

SEC Financial Explorer Supports XBRL Interactive Data
Staff, U.S. Securities and Exchange Commission

The U.S. Securities and Exchange Commission (SEC) has announced the launch of the "Financial Explorer" on the SEC Web site to help investors quickly and easily analyze the financial results of public companies. XBRL is a member of the family of languages based on XML (Extensible Markup Language), which is a standard for the electronic exchange of data between businesses and on the internet. Under XML, identifying tags are applied to items of data so that they can be processed efficiently by computer software. Financial Explorer paints the picture of corporate financial performance with diagrams and charts, using financial information provided to the SEC as "interactive data" in Extensible Business Reporting Language (XBRL). At the click of a mouse, Financial Explorer lets investors automatically generate financial ratios, graphs, and charts depicting important information from financial statements. Information including earnings, expenses, cash flows, assets, and liabilities can be analyzed and compared across competing public companies. The software takes the work out of manipulating the data by entirely eliminating tasks such as copying and pasting rows of revenues and expenses into a spreadsheet. That frees investors to focus on their investments' financial results through visual representations that make the numbers easier to understand. Financial Explorer is open source software, meaning that its source code is free to the public, and technology and financial experts can update and enhance the software. As interactive data becomes more commonplace, investors, analysts, and others working in the financial industry may develop hundreds of Web-based applications that help investors garner insights about financial results through creative ways of analyzing and presenting the information. In addition to Financial Explorer, the SEC currently offers investors two other online viewers—the Executive Compensation viewer and the Interactive Financial Report viewer, also available at online. The Executive Compensation viewer enables investors to instantly compare what 500 of the largest U.S. companies are paying their top executives. The Interactive Financial Report viewer also helps investors gather, analyze, and compare key financial disclosures filed voluntarily by public companies using XBRL. To date, there have been 307 such filings from 74 companies. Under the SEC's interactive data filing program, companies may continue to file XBRL data voluntarily, pending anticipated Commission rulemaking.

W3C Last Call Working Draft: CSS Namespaces Module
Elika J. Etemad and Anne van Kesteren (eds), W3C Technical Report

W3C announced the release of an updated, Last Call Working Draft for the "CSS Namespaces Module" specification, updating the previous WD published 2006-08-28. The previous draft was edited by Peter Linss and Chris Lilley. The deadline for comments is 7-March-2008. This CSS Namespaces Module defines syntax for using namespaces in CSS. It defines the '@namespace' rule for declaring a default namespace and for binding namespaces to namespace prefixes. It also defines a syntax for using those prefixes to represent namespace-qualified names. It does not define where such names are valid or what they mean: that depends on their context and is defined by a host language, such as Selectors, that references the syntax defined in the CSS Namespaces module. Note that a CSS client that does not support this module will, if it properly conforms to CSS's forward-compatible parsing rules, ignore all '@namespace' rules, as well as all style rules that make use of namespace qualified names. The syntax of delimiting namespace prefixes in CSS was deliberately chosen so that these CSS clients would ignore the style rules rather than possibly match them incorrectly. A document or implementation cannot conform to CSS Namespaces alone, but can claim conformance to CSS Namespaces if it satisfies the conformance requirements in this specification when implementing CSS or another host language that normatively references this specification. Conformance to CSS Namespaces is defined for two classes: (1) style sheet: a CSS style sheet or a complete unit of another host language that normatively references CSS Namespaces; (2) interpreter: someone or something that interprets the semantics of a style sheet, where CSS user agents fall under this category. CSS is the Web's primary style sheet language for specifying the rendering of text documents, in particular those expressed in HTML and XML-based formats. It can also be used to specify portions of the rendering of certain non-text formats, such as SMIL (multimedia) and SVG (vector graphics). The model of text-flow and the set of properties of CSS are also shared with XSL, W3C's style language for complex formatting of XML-based document formats, though XSL is developed by a separate WG. In addition to visual output (screen, print), CSS also contains styling properties for speech output. The CSS WG develops and maintains the CSS language and related technologies. CSS allows both authors and readers to specify the display or other rendering of documents, such as those in HTML or SVG. CSS has several levels, from simple (level 1) to complex (level 3) and several 'profiles,' which describe how CSS applies on different media (TV, handheld, etc.). Level 1 is a Recommendation, level 2 is in maintenance, level 3 is currently being developed.

OASIS TC Publishes Code List Representation (Genericode) Version 1.0

G. Ken Holman announced that "Code List Representation (Genericode) Version 1.0" (Committee Specification 01) has been published, and is available online. Edited by Anthony B. Coates on behalf of the OASIS Code List Representation TC, this document describes the OASIS Code List Representation model and W3C XML Schema, known collectively as 'genericode'. Code lists, or enumerated values, have been with us since long before computers. Most people would agree that the following is a code list: {'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'}. Code lists should be well understood and easily dealt with by now. Unfortunately, they are not. As is often the case, if you take a fundamentally simple concept, you find that everyone professes to understand it with complete clarity. When you look more closely, you find that everybody has their own unique view of what the problem is and how it should be solved. If code lists were really so simple and obvious, there would already be a single, well-known and accepted way of handling them in XML. There is no such agreed solution, though. The problem is that while code lists are a well understood concept, people don't actually agree exactly on what code lists are, and how they should be used. The OASIS Code List Representation format, 'genericode', is a single model and XML format (with a W3C XML Schema) that can encode a broad range of code list information. The XML format is designed to support interchange or distribution of machine-readable code list information between systems. Note that genericode is not designed as a run-time format for accessing code list information, and is not optimized for such usage. Rather, it is designed as an interchange format that can be transformed into formats suitable for run-time usage, or loaded into systems that perform run-time processing using code list information. There are 3 kinds of genericode documents, all supported by the one W3C XML Schema: (1) Column Set documents (contain definitions of genericode columns or keys that can be imported into code list documents or into other column set documents); (2) Code List documents (contain metadata describing the code list as a whole, as well as explicit code list data—codes and associated values); (3) Code List Set documents (contain references to particular versions of code lists, and can also contain version-independent references to code lists; a code list set document can be used to define a particular configuration of versions of code lists that are used by a project, application, standard, etc.). Work on the corresponding CVA formats is still underway.

See also: the Requirements

XML 1.0 (Fifth Edition)
Norm Walsh, Blog

The fifth edition of XML 1.0 is now a 'Proposed Edited Recommendation' (PER). New editions do little more than incorporate errata, hardly newsworthy. This one is different. Fifth Edition is now out for review. The review period is long, lasting until 16-May-2008, because one of the proposed changes is significant. Before the fifth edition, XML 1.0 was explicitly based on Unicode 2.0. As of the fifth edition, it is based on Unicode 5.0.0 or later. This effectively allows not only characters used today, but also characters that will be used tomorrow. One of the real strengths of XML from the very beginning was that it required processors to support Unicode. This made XML, and all XML processors, international. But as Unicode has been extended to support languages written in Cherokee, Ethiopic, Khmer, Mongolian, Canadian Syllabics, and other scripts, XML 1.0's explicit use of Unicode 2.0 has prevented it from growing as well. That's a problem that XML must fix if it wants to continue to be regarded as a universal text format... The fifth edition does not change the status of any existing XML 1.0 document with respect to well-formedness or validity. Nor does it introduce any of the backwards-incompatible changes introduced in XML 1.1. It isn't entirely without pain, unfortunately. Even if we imagine that all parsers will be updated to reflect the fifth edition (and it's possible to be optimistic on this point as it actually makes parsers smaller and simpler) eventually, there will be some period of time in which your (fourth edition) parser might reject my (fifth edition) document. The XML Core WG is taking the position that the benefits of extending XML 1.0 in this way outweigh the costs imposed by the change. It remains to be seen if the community will agree. Bear in mind that this sort of change isn't entirely unprecedented, we previously decoupled 'xml:lang' attributes from the relevent RFCs and we tinkered with the specific version of Unicode 3 referenced. That said, this is still a much more substantial change.

OASIS Members Submit Charter for ebXML Core (ebCore) Technical Committee
Staff, OASIS Announcement

OASIS announced the submission of a draft charter for a new ebXML Core (ebCore) Technical Committee. The ebXML Core TC is to be the maintenance group for ebXML TC specifications as these specifications are completed or transitioned to the ebXML Core TC. The OASIS ebXML Joint Committee is disbanding, so ebXML Core TC will take on the roles and the work of the ebXML JC, and in addition will do maintenance on the standards that have been produced by the ebXML TCs: ebXML Messaging, ebXML CPPA, ebXML ebBP, ebXML IIC, and ebXML RegRep. Companies represented by the TC proposers include Axway Software, The Boeing Company, British Telecommunications plc, Fujitsu Limited, and Sonnenglanz Consulting. The ebXML Core TC will provide the means to manage clarifications, modifications, and enhancements for the specifications that ebXML TCs have either completed and/or turned over as work in progress for completion through the OASIS standards process. The ebXML Core TC may issue errata for specifications that they maintain and may complete reviews and changes required by editor's on committee drafts received by the TC for completion. The ebXML Core TC may form subcommittees to provide focus for specific specification tasks as they arise. The ebXML Core TC may lead the formation of charters for new ebXML TCs for major new versions of specifications. The TC may also produce new conformance profiles and adjunct documents complementing existing specifications. The ebXML Core TC will solicit new end user requirements as well as implementation enhancements and change requests. The TC will also explore synergies with UN/CEFACT, WS-* specifications and SOA best practices. The ebXML Core TC may update schemas, examples, specifications and other products of ebXML TC activities.

SourceForge: Office Binary (doc, xls, ppt) Translator to Open XML Project
Brian Jones, Blog

"As promised last month, the binary documentation (.doc, .xls, .ppt) is now live. In addition to this, the project to create an open source translator (binary to Open XML) has now been formed on SourceForge, and the development roadmap has been published. While the project is still in its infancy, you can see what the planned project roadmap is, as well as an early draft of a mapping table between the Word binary format (.doc) and the Open XML format (.docx). The binary documentation itself is also available; it's all covered under the Open Specification Promise. Another great surprise in all of this is that we've made the documentation for a few other supporting technologies available as it may be of use to folks implementing the binary formats: (1) Windows Compound Binary File Format Specification; (2) Windows Metafile Format (.wmf) Specification; (3) Ink Serialized Format (ISF) Specification..." From the Overview: "The main goal of the Office Binary (doc, xls, ppt) Translator to Open XML project is to create software tools, plus guidance, showing how a document written using the Binary Formats (doc, xls, ppt) can be translated into the Office Open XML format. As a result customers can use these tools to migrate from the binary formats to Office Open XML Format thus enabling them to more easily access their existing content in the new world of XML. The Translator will be available under the open source Berkeley Software Distribution (BSD) license, which allows that anyone can use the mapping, submit bugs and feedback, or contribute to the project. On February 15th 2008, Microsoft has made it even easier to get access to the binary formats documentation from [the Microsoft Office Binary File Formats web site], and the binary formats have also been made available under the Microsoft Open Specification Promise. The Office Open XML file format has been approved as an Ecma standard and is available [online]. We have chosen to use an Open Source development model that allows developers from all around the world to participate and contribute to the project.

See also: the SourceForge Project


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

Headlines

Sponsors