Cover Pages: XML Daily Newslink: Tuesday, 29 May 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:
Sun Microsystems, Inc. http://sun.com

Headlines

POWDER: Use Cases and Requirements
Astoria On-Demand Tames Complex Documents
Bringing It All Together: SOA Design for Data-Sharing Links
Reliability in SOA is HUGE
OASIS Digital Signature Services Extended (DSS-X) Technical Committee

POWDER: Use Cases and Requirements
Phil Archer (ed), W3C Technical Report

W3C's POWDER Working Group announced the release of a first publication for "POWDER: Use Cases and Requirements." The W3C Protocol for Web Description Resources (POWDER) Working Group was chartered to specify an RDF vocabulary for specifying authorship of and authentication of Description Resources, a specification for associating a Description Resource with a class of Web resources, predicates for declaring classes of resources based on string functions of the resource URIs, and a protocol for accessing Description Resources. A Description Resource (DR) must be able to describe aspects of a group of information resources using terms chosen from different vocabularies. Such vocabularies might include, but are not limited to, those that describe a resource's subject matter, its suitability for children, its conformance with accessibility guidelines and/or Mobile Web Best Practice, its scientific accuracy and the editorial policy applied to its creation. This Working Group Note will guide the development of a way to attach small, easily-produced annotations to large collections of Web content. Web resources can then be retrieved, personalized and delivered in a variety of delivery contexts to meet both social needs for content labels and commercial requirements for content adaptation.

See also: the Working Group Charter

Astoria On-Demand Tames Complex Documents
Mike Heck, InfoWorld

Most enterprises drive their Web sites and intranets using a CMS. That's because CMSes offer consistent branding, easy editing, content reuse, and approval workflows. Unfortunately, publishing systems for producing structured technical manuals came late to the party in delivering these benefits Astoria On-Demand provides a highly usable and quickly deployed hosted system based on OASIS' DITA (Darwin Information Typing Architecture) standard. This easy-to-use solution enables remote teams to author, review, and publish XML-based technical documents. On-Demand manages content as elements (which can be reused), provides automated workflow, and publishes to multiple formats—with the short implementation and predictable cost provided by the SaaS model. I found using the system straightforward, after I brushed up on some DITA concepts (which should take new users a few days at most). To begin, the visual Web interface is arranged into logical areas. On the left, much like Microsoft Word's Document Map feature, Astoria's Map Editor structures content into standard DITA topics, references, and tasks that appear in a hierarchical tree. Modifying content in the XML editor is swift; Astoria bundles Parametric Technology's popular Arbortext Editor. Familiar text and image formatting options appear in a toolbar, and a variety of other options (such as selecting content for re-use or showing revision history) are found within clearly labeled menus. Astoria On-Demand demystifies other complex tasks; for instance, Astoria Document Assembly (a built-in application) creates new documents for you from components and topics stored in the repository. Moreover, these technical bulletins, data sheets, and operator manuals are dynamically updated to reflect changes in the single copy of the underlying content.

See also: DITA references

Bringing It All Together: SOA Design for Data-Sharing Links
David Essex, Government Computer News

For decades, the Defense Department and intelligence agencies cultivated a garden of specialized technologies that shifted classified data -- typically files, text chat and e-mail—across security classifications and network domains. As a result, there are now more than 800 of these cross-domain interfaces, most of them customized. Simplification of the cross-domain offerings has been in the works for at least a year. The chief intelligence officers of the Pentagon and the Office of the Director of National Intelligence (ODNI) created the Cross Domain Management Office (CDMO) in March 2006 to choose a baseline group of the cross-domain entities and mandate their exclusive use. The tentative result is a baseline set of about 15 cross-domain interfaces and 10 exceptions covering special cases. More than 750 cross-domain interface projects won't make the cut... The SOA and XML models embedded in those law enforcement systems figure prominently in the technological work of the Information Sharing Environment, an agency that reports to the ODNI. ISE systems architects have defined architecture requirements that apply to new systems in about 20 agencies with primary responsibilities for counterterrorism work. OMB enforces the ISE technology requirements, including their SOA features, via the Form 300 submissions that federal agencies must provide before receiving funding for new systems.

Reliability in SOA is HUGE
Nick Malik, Blog

Reliability takes many forms, but the definition that I work from comes from the IEEE. IEEE 610.12-1990 defines Reliability as "The ability of a system or component to perform its required functions under stated conditions for a specified period of time." The reason that this becomes a problem in SOA is because the basic strength of SOA is the message, and the weakest link is the mechanism used to move the message. If we create a message but we cannot be certain that it gets delivered, then we have created a point of failure that is difficult to surpass. One friend of mine, Harry Pierson, likes to point out that the normal notion of 'Reliable Messaging' is not sufficient to provide system reliability. You need more. You need durable messaging. Durable messaging is more than reliable messaging, in his lexicon, because durable messages are stored and forwarded. Therefore, if a system goes down, you can always rely on the storage mechanism to keep it from being lost. Reliable messages are kept in memory and simply retried until acknowledged, but lost if the sending system goes down during the process... I view reliability as a measurable condition of a system, usually measured in Mean Time Between Failure (MTBF). What becomes clear from this thread is this: in order to increase system reliability, especially in a system based on messages, we need to insure message delivery, and the best way to do this is through message durability.

OASIS Digital Signature Services Extended (DSS-X) Technical Committee
Staff, OASIS Announcement

OASIS announced a charter proposal for a Digital Signature Services Extended (DSS-X) Technical Committee. As drafted, the proposed Technical Committee "has as its mandate production of new profiles of the existing OASIS Digital Signature Services core protocol 'Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0' and maintenance of this specification and its existing profiles. If at a later date it becomes clear that a new version of DSS is necessary then this may be produced by the TC. This further includes promotion of the standard and the creation of material helping dissemination. In general terms, the TC has the goal to facilitate the processing of digital signatures and time stamps in a client server environment. In-scope topics include (1) support of the server-based creation and verification of different types of signatures, among which the most relevant ones are XML Sig and CMS, and timestamps, both RFC 3161 and the XML time-stamps defined by the OASIS Digital Signature Services (DSS) TC; (2) production of new profiles suitable for a number of environments and purposes, which spread the usage of the specifications; (3) production of an analysis of inter-relationship among existing profiles in a matrix where new profiles shall state their relationship to existing ones; (4) production of dissemination material for promoting usage and facilitating tools development; (5) maintenance of the existing OASIS DSS standard and core protocol and related profiles produced by the former OASIS Digital Signature Services Technical Committee, subject to appropriate access to underlying intellectual property.


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

Headlines

Sponsors