|
XML and Web Services In The News - 19 December 2006
Provided by OASIS |
Edited by Robin Cover
This issue of XML Daily Newslink is sponsored by Sun Microsystems, Inc.
HEADLINES:
Universal Business Language (UBL) V2.0 Approved as OASIS Standard
Staff, OASIS Announcement
OASIS has announced approval of the Universal Business Language (UBL)
Version 2.0 as an OASIS Standard, a status that signifies the highest
level of ratification. UBL defines a royalty-free library of standard,
electronic XML business documents such as purchase orders and invoices.
UBL formats in electronic messages enable direct connection into
existing business, legal, auditing, and records management practices,
eliminating the re-keying of data in existing fax- and paper-based
supply chains and providing an entry point into electronic commerce for
small- and medium-sized businesses. UBL 2.0 features a library of more
than one thousand XML data elements based on the ebXML Core Components
Technical Specification (ISO 15000-5). Building on the eight core
order-to-invoice document types in UBL 1.0, version 2.0 adds twenty-three
(23) new document types to accommodate extended procurement scenarios
and basic transport processes. Development of these new schemas was
funded directly or indirectly by the governments of Denmark, Norway,
Sweden, England, Finland, Iceland, Singapore, Hong Kong, and the United
States. In addition to greatly expanding the range of business processes
supported by UBL, version 2.0 also taps the power of W3C XSLT, W3C XPath,
and ISO Schematron to provide a breakthrough in code list management.
Tim McGrath, vice chair of the OASIS UBL Technical Committee: "Employing
the new 'genericode' XML specification for code list publication
currently under development in OASIS, our approach allows trading
partners to easily and precisely specify code list subsets and extensions
and even to apply them to particular elements and subtrees within UBL
instances — all without changing the standard UBL schemas. Once in
place, this standards-based process enables the implementation of
business rule checking as part of instance validation. Open source
software included in the UBL 2.0 release provides this new functionality
'out of the box.'"
See also: UBL references
Speech Synthesis Markup Language Version 1.1 Requirements
Chimezie Thomas-Ogbuji, XML 2006 Presentation
W3C's Voice Browser Working Group has released a First Public Working
Draft for the "Speech Synthesis Markup Language Version 1.1 Requirements."
The specification establishes a prioritized list of requirements for
speech synthesis markup which any proposed markup language should address.
This document addresses both procedure and requirements for the formal
specification development. In addition to general requirements, the
requirements are addressed in separate sections on Speech Interface
Framework Consistency, Token/Word Boundary, Phonetic Alphabet and
Pronunciation Script, Language Category, and Name/Proper Noun
Identification Requirements. In 2005 and 2006 the W3C held workshops to
understand the ways, if any, in which the design of SSML 1.0 limited its
usefulness for authors of applications in Asian, Eastern European, and
Middle Eastern languages. In 2006 an SSML subgroup of the W3C Voice
Browser Working Group was formed to review this input and develop
requirements for changes necessary to support those languages. An
encouraging result from the workshops was that many of the problems
might be solvable using similar, if not identical, solutions. In fact,
it may be possible to increase dramatically the usefulness of SSML for
many application authors around the world by making a limited number
of carefully-planned changes to SSML 1.0. That is the goal of this
effort.
See also: W3C Voice Browser Activity
Daddy? Where do Schemas Come From?
C. M. Sperberg-McQueen, XML 2006 Presentation
This paper given at XML 2006 (Boston, December 2006) presents some facts
of life for users of XML Schema 1.0. Michael Sperberg-McQueen is a
member and staff contact of the W3C XML Schema Working Group, and
co-editor of XML Schema 1.1. "New users of XML Schema 1.0 are often
puzzled by the rules for locating schema documents and building a
schema to validate a document. More experienced users, and even
implementors of schema processors, are sometimes mystified, too. How
does a validator find components? Why on earth is the 'schemaLocation'
attribute only a hint? This paper reviews the differences between
schemas and schema documents, the rules for constructing a schema from
schema documents or other sources, and some of the reasoning behind the
design. First, note that a schema, as the term is used by the XML Schema
1.0 specification, is an abstract object, a set of (equally abstract)
schema components. It is not a particular data structure, file format,
or XML vocabulary, although all of those may be used to represent all
or part of a schema. A schema document, by contrast, is a (more)
concrete thing: it's an XML document that uses a particular vocabulary
to describe schema components. Strictly speaking, a schema document
need not be an XML document; any element will do if it's named
[correctly] and a local name of "schema" and if it conforms to the
rules of the vocabulary. This means, among other things, that schemas
can be included in the same XML document as the elements they are
expected to validate. Most schema processors do support the XML
representation of schema documents defined by the XSD 1.0 spec, but a
'minimally conforming' processor is not required to: such a processor
may read schemas from binary representations, or load them from a
special-purpose schema repository, or have a schema hard-coded into
the software. It's also possible for a schema processor to support
other human-readable syntaxes, although no widely used schema
processors do so today. You prefer Relax NG syntax, but don't require
non-deterministic content models? Encourage your vendor to support
Relax NG syntax. You want a compact notation? Encourage your vendor
to support the compact XSD notation developed by Erik Wilde and
Killian Stillhard. You really like DTD syntax? There is DTD++, a
syntax for writing XSD schemas developed at the University of Bologna.
See also: XML Schema languages
W3C Releases SOAP 1.2 Part 3: One-Way MEP
David Orchard (ed), W3C Technical Report
The W3C XML Protocol Working Group has released a First Public Working
Draft for the "SOAP 1.2 Part 3: One-Way MEP". SOAP Version 1.2 Part 2
provides a request-response Message Exchange Pattern (MEP) and a
response-only MEP. This document the SOAP 1.2 Part 3, defines a one-way
MEP. The SOAP One-way MEP defines properties for the exchange of a SOAP
message. In the absence of failure in the underlying protocol, this MEP
consists of zero or more SOAP messages. The scope of a one-way MEP is
limited to transmission of (nearly) identical messages from one sending
node to zero or more receiving SOAP node(s); typically, in the case of
multiple receivers, the messages differ only in their destinations.
Implementations MAY choose to support multiple meps at the same time.
The "InboundMessage" property is an abstract structure that represents
the current inbound message in the message exchange. This abstracts
both SOAP Envelope and any other information structures that are
transferred along with the envelope. "OutboundMessage" is an abstract
structure that represents the current outbound message in the message
exchange. "ImmediateDestination" provides an identifier for the
immediate destination of an outbound message. The URI supplied MAY be
the identifier of a single destination SOAP node, or MAY be the
identifier of a multicast group, which itself consists of zero or more
destination nodes. Whether multicast is supported is binding-dependent.
This MEP specification provides no standard means for representing a
multicast group, except to require that the group as a whole be
designated by a URI. "ImmediateSender" is the identifier of the
immediate sender of an inbound message.
See also: the W3C XML Protocol Working Group
Build Ajax Into Your Web Applications With Rails
Jack D. Herrington, IBM developerWorks
Ruby on Rails provides a platform for building Web applications. In
this article you will discover how to use the built-in Asynchronous
JavaScript + XML (Ajax) features of the platform to give an application
the Web 2.0 rich user interface experience. Rails is a Web applications
platform built on top of the Ruby programming language. Ruby has been
around for about 10 years. Like Perl and Python, it's an open source,
agile programming language that offers full support for object-oriented
programming. Rails is an applications framework that emphasizes proper
Web application patterns, such Model-View-Controller (MVC). In this case,
the Model portion of the system is generally represented by a set of
ActiveRecord objects that map to the tables in a database. The Controller
portion is a Ruby class with methods for each of the various operations
to perform on the model. And the View is typically Hypertext Markup
Language (HTML) code generated through an ERB template (ERB is Ruby's
built-in text templating package), which feels similar in form to PHP or
JavaServer Pages (JSP) code. Views can also be Extensible Markup Language
(XML) code, text, JavaScript code, images, or whatever you like. When a
user requests a page from a Rails Web application, the URL is sent
through a routing system, which sends the request to a controller. The
controller requests data from the model and sends it to the view for
formatting. When you create a Rails application, the system automatically
generates a set of directories and starting files. There are directories
for the JavaScript files that come with the system (including the
Prototype.js library); directories for the views, models, and
controllers; and even a location for plug-ins that you can download
from other developers.
Rolling with Ruby on Rails Revisited
Bill Walton and Curt Hibbs, O'Reilly ONLamp.com
Ruby is a pure object-oriented programming language with a super-clean
syntax that makes programming elegant and fun. Ruby successfully
combines Smalltalk's conceptual elegance, Python's ease of use and
learning, and Perl's pragmatism. Ruby originated in Japan in the early
1990s. It has become popular worldwide in the past few years as more
English-language books and documentation have become available. Rails
is an open source Ruby framework for developing web-based, database-
driven applications. What's special about that? There are dozens of
frameworks out there, and most of them have been around much longer
than Rails... Rails takes full advantage of Ruby. Two of Rails'
guiding principles: less software and convention over configuration.
Less software means you write fewer lines of code to implement your
application. Keeping your code small means faster development and
fewer bugs, which makes your code easier to understand, maintain, and
enhance. Very shortly, you will see how Rails cuts your code burden.
Convention over configuration means an end to verbose XML
configuration files — there aren't any in Rails! Instead of
configuration files, a Rails application uses a few simple programming
conventions that allow it to figure out everything through reflection
and discovery. Your application code and your running database already
contain everything that Rails needs to know.
Open SOA Collaboration: The Birth of Another Standard
David Linthicum, Web 2.0 Journal
Last month an alliance of leading vendors announced progress on
specifications to define a language-neutral programming model for
application development in SOA environments. They call this
specification Open SOA Collaboration. In essence, they are proposing a
new standard to create and manage IT, making the process of integrating
different third-party SOA technologies "less onerous," they say. Or, we
can call this a standard way of delivering services, making it easier to
work and play well together. BEA, IBM, Oracle, and SAP first got
together last November to begin work on the common programming model,
along with Iona, Sybase, Xcalia SA, and Zend Technologies Ltd. Others
are joining the mix, including Software AG and Red Hat. This group has
concentrated its efforts on two projects — service component
architecture (SCA) and service data objects (SDO). If this sounds
familiar, it is. We've seen this type of standard with components,
distributed objects, and, more recently, Java. SCA is looking to provide
a model for creating service components in a wide range of languages
and a model for assembling service components in a business solution.
In essence this is a standard that defines how services are created so
they interact with each other without a lot of customization. This will
benefit those who are looking to create composite applications that use
these services. SCA encourages an SOA organization of business
application code based on components that implement business logic. It
offers capabilities through services that consume functions offered by
other components through services called references. SCA divides up
the steps in building a service-oriented application into two major
parts: The implementation of components that provide services and
consume other services and the assembly of sets of components to build
business applications by wiring references to the services... It will
be interesting to see where this standard goes in the context of BPEL
and other standards that provide the same solution patterns. At the
end of the day, standards are only useful if there's one for each
problem pattern. So far in the world of SOA, we have three or more
standards for each problem pattern. Those who consume the technology
won't touch standards until the problem is solved.
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. |
