Date:
Sun, February 17, 2008 09:58:41 PMFrom:
Robin Cover
Subject:
XML Daily Newslink. Friday, 15 February 2008
XML Daily Newslink. Friday, 15 February 2008
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
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.
http://dev2dev.bea.com/blog/vijay.mandava/archive/2008/02/wls_103_tech_pr_1.html
See also the OASIS Open Composite Services Architecture (CSA) Member Section: http://www.oasis-opencsa.org/
----------------------------------------------------------------------
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.
http://xml.coverpages.org/SEC-FinancialExplorer-XBRL
See also the Financial Explorer web site: http://www.sec.gov/xbrl
----------------------------------------------------------------------
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.
http://www.w3.org/TR/2008/WD-css3-namespace-20080215/
See also the CSS Working Group Charter 2006-2008: http://www.w3.org/Style/2004/css-charter-long
----------------------------------------------------------------------
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.
http://docs.oasis-open.org/codelist/cs-genericode-1.0/doc/oasis-code-list-representation-genericode.html
See also the Requirements: http://docs.oasis-open.org/codelist/cd-genericode-1.0/doc/oasis-code-list-representation-requirements-1.0.1.pdf
----------------------------------------------------------------------
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.
http://norman.walsh.name/2008/02/07/xml105e
See also the XML-DEV discussion thread: http://lists.xml.org/archives/xml-dev/200802/threads.html#00220
----------------------------------------------------------------------
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.
http://lists.oasis-open.org/archives/tc-announce/200802/msg00004.html
----------------------------------------------------------------------
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.
http://blogs.msdn.com/brian_jones/archive/2008/02/15/binary-documentation-doc-xls-ppt-and-translator-project-site-are-now-live.aspx
See also the SourceForge Project: http://b2xtranslator.sourceforge.net/
----------------------------------------------------------------------
XML Daily Newslink and Cover Pages are sponsored by:
BEA Systems, Inc. http://www.bea.com
EDS http://www.eds.com
IBM Corporation http://www.ibm.com
Primeton http://www.primeton.com
SAP AG http://www.sap.com
Sun Microsystems, Inc. http://sun.com
----------------------------------------------------------------------
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter ***: newsletter-***@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/
----------------------------------------------------------------------


Back to newsletter list