Cover Pages: XML Daily Newslink: Friday, 28 December 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

WSO2 Registry Version 0.1
Using Intelligence Community Security Markings (IC-ISM) with NIEM
W3C Last Call Working Drafts for SVG Print 1.2 (Language, Primer)
Fedora 3.0 Beta Features Content Model Architecture (CMA)
OAI Object Reuse and Exchange (ORE) Specification and User Guide
Device Description Repository Core Vocabulary
Enable the WSDM Event Format using the Generic Log Adapter

WSO2 Registry Version 0.1
Paul Fremantle, Blog

On behalf of the WSO2 Registry team, Paul Fremantle announced the version 0.1 release of the WSO2 Registry. "This early release demonstrates a completely REST-based approach to storing, searching and managing SOA metadata. The Registry stores any kind of resource in a simple JDBC driven store, and uses AtomPub as a web API to allow publishing and searching. The Registry has been deliberately designed to bring social interaction to the world of SOA metadata by including tagging, comments, rating and a wiki-like approach to SOA registries... WSO2 Registry enables you to store, catalog, index and manage your enterprise meta data in a simple, scalable and easy-to-use model. It is designed around community concepts such as tags, comments, ratings, users and roles. Think of the registry as a structured wiki designed to help you manage your meta-data in a simple business-friendly system. In addition, the registry allows you to store more unstructured data such as Word documents, Excel spreadsheets and text formats. Using these approaches, you can build a catalog of enterprise information ranging from services, service descriptions to employee data and on going projects. WSO2 Registry can be deployed in Application Servers and access using the Web UI or the APP interface. It can also be used as a Java library inside other Java programs as a resource store with all community features and versioning."

See also: 'WSO2 goes all RESTy'

Using Intelligence Community Security Markings (IC-ISM) with NIEM
Staff, NIEM Announcement

NIEM (National Information Exchange Model) is a partnership of the U.S. Department of Justice and the Department of Homeland Security. Developers recently announced an interim solution designed to allow users to use IC-ISM within NIEM 2.0. The IC-ISM standard is an XML Schema described in the IC-ISM Data Element Dictionary and the Implementation Guide. It is one of the Intelligence Community (IC) Metadata Standards for Information Assurance and is the preferred way to apply information security markings within XML instances. Until recently, the schema for the Intelligence Community Information Security Marking (IC-ISM) standard was considered for official use only (FOUO) and could not be published. Therefore, NIEM 2.0 could not integrate components of IC-ISM without publishing the IC-ISM schema. Actions have now been taken to restore the ability to use IC-ISM within NIEM 2.0 and future releases. To facilitate the preferred (future) use of the IC-ISM standard in NIEM will require, in sequence: (1) Completion of the NIEM versioning architecture; (2) A forward-compatible release update to NIEM 2.0; (3) Minor change(s) to the NIEM NDR; (4) Governance Committee review and approval.

W3C Last Call Working Drafts for SVG Print 1.2 (Language, Primer)
Alex Danilo and Craig Northway (et al., eds), W3C Technical Reports

W3C announced that the SVG Working Group has published Last Call Working Drafts for the "SVG Print 1.2, Part 2: Language" and "SVG Print 1.2, Part 1: Primer" specifications. The "Language" document defines features of the Scalable Vector Graphics (SVG) Language that are specifically for printing environments. The "Primer" explains the technical background and gives guidelines on how to use the SVG Print specification with SVG 1.2 Tiny and SVG 1.2 Full modules for printing; it is purely informative and has no conformance statements. Because of its scalable, geometric nature, SVG is inherently better suited to print than raster image formats. The same geometry can be displayed on screen and on a printer, with identical layout in both but taking advantage of the higher resolution of print media. The same colors can be output, using an ICC-based color managed workflow on the printer and an sRGB fallback approximation on screen. This has been true since SVG 1.0, and so SVG has been used in print workflows (for example, in combination with XSL FO) as well as on screen. However, SVG also has dynamic, interactive features such as declarative animation, scripting, timed elements like audio and video, and user interaction such as event flow and link activation. None of these are applicable to a print context. SVG 1.1 gives static and dynamic conformance classes, but further guidance on what exactly SVG Printers should do with such general content is helpful. The SVG Print specification defines processing rules for handling such general purpose content which was not designed to be printed, but which may be encountered anyhow. It is possible to generate SVG which is exclusively intended for print (for example, a printer which natively understands SVG). This content might be created in an illustration program, or it might be an output from a layout program, such as an XSL-FO renderer; or it might be generated by an SVG Print driver. W3C's Graphics Activity has been developing graphics specifications for over ten years: "Scalable Vector Graphics (SVG), the current effort of the Activity, brings the powerful combination of interactive, animated two-dimensional vector graphics and Extensible Markup Language (XML). WebCGM 2.0 is used mainly in industrial and defence technical documents. Earlier work was concerned with Portable Network Graphics (PNG) and with WebCGM 1.0."

See also: the SVG Print 1.2, Part 1

Fedora 3.0 Beta Features Content Model Architecture (CMA)
Staff, Fedora Commons Project

A Beta release of "Content Model-driven Fedora 3.0" has been announced by the Fedora Commons Project developers. The CMA is described as a powerful, new integrated structure for persisting and delivering the essential characteristics of digital objects in Fedora while simplifying its use. Fedora Commons is the home of the unique Fedora open source software, a robust integrated repository-centered platform that enables the storage, access and management of virtually any kind of digital content. Prior implementations of the Fedora Repository utilized a set of specialized digital objects as a functional and persistence framework. All of these objects conform to the same basic object model. Digital objects in CMA are conceptually similar in prior versions of Fedora though some important implementation details have changed. Fedora still implements a compound digital object design consisting of an XML encapsulation (now FOXML 1.1) and a set of bitstreams identified by the "Datastream" XML element. FOXML is a simple XML format that directly expresses the Fedora digital object model. We can also assemble multi-object groups of related digital objects as before using semantic technologies. In the CMA, the "content model" is defined as a formal model that describes the characteristics of one or more digital objects. A digital object may be said to conform to a content model. In the CMA, the concept of the content model is comprehensive, including all possible characteristics which are needed to enable persistence and delivery of the content. This can include structural, behavioral and semantic information. It can also include a description of the permitted, excluded, and required relationships to other digital objects or identifiable entities. "Following the rules of Fedora identifiers, the identifier of the CModel object can be encoded within a URI. We will describe the rationale for this decision in a later section but this approach provides two immediate benefits: (1) it provides a scheme which works within the Fedora architecture with minimal impact, and (2) it is compatible with the Web architecture, RDF and OWL. We can even build functionality using just the knowledge of the identifier without creating a content model. Having a uniform method for identifying a digital object's class maximizes interoperability..."

See also: the documentation

OAI Object Reuse and Exchange (ORE) Specification and User Guide
Carl Lagoze and Herbert Van de Sompel (eds), OAI Draft Specification

Members of the Open Archives Initiative announced the release of a an "ORE Specification and User Guide" for comment. Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. The ORE Model makes it possible to associate an identity with aggregations of web resources and to describe their structure and semantics. It does this by introducing the Resource Map (ReM), which is a resource identified by a URI (say ReM-1) that encapsulates a set of RDF statements. These statements instantiate an aggregation as a resource with a URI, enumerate the constituents of the aggregation, the relationships among those constituents, and the Web context of the aggregation. The ORE Model can be serialized in a variety of formats which will be described, along with mappings of ORE Model concepts, in companion ORE documents. The "ORE Abstract Data Model" document describes the abstract data model that is the foundation for the collection of ORE standards. This model is conformant with the Architecture of the World Wide Web and leverages Named Graphs ['Named Graphs, Provenance and Trust'] as a mechanism for encapsulating RDF descriptions about aggregations. A Resource Map Document is a machine-readable representation of a Resource Map. A Resource Map Document can be serialized in different formats, and the purpose of the "ORE User Guide Resource Map Implementation in Atom" document is to specify a serialization based on, and compliant with the Atom syndication format. Hereby, a Resource Map Document is an Atom Feed Document with some ORE-specific ingredients. This Atom-based format to serialize Resource Map Documents may be referred to as the Resource Map Profile of Atom.

Device Description Repository Core Vocabulary
Andrea Trasatti, Rotan Hanrahan, Jo Rabin (eds), W3C Technical Report

Members of W3C's Mobile Web Initiative Device Description Working Group have published the First Public Working Draft for the "Device Description Repository Core Vocabulary" specification. The MWI Device Description Working Group (DDWG) was chartered to enable the development of globally accessible, sustainable data and services that provide device description information applicable to content adaptation. The DDR "Core Vocabulary" document identifies key device properties that may be represented in an initial instance of a device description repository that supports content adaptation for mobile devices. It also describes the process by which the vocabulary was defined. The identification of these properties has been informed by previous work of the DDWG as well as input from other W3C groups—in particular the Mobile Web Initiative Best Practice Working Group and the Ubiquitous Web Applications Working Group—and external contributors. The vocabulary makes reference to the UWA ontology ("Delivery Context Ontology") for the Web delivery context. The vocabulary defined in the document is not intended to represent an exhaustive set of properties for content adaptation. DDR Implementations that require additional properties are free to make use of additional vocabularies. The process of creating a new vocabulary can be modelled on the process described in this document. Implementors are encouraged to make use of the UWA ontology. Where necessary, the ontology can be extended. Implementors of DDR solutions that are intended to support content adaptation for mobile Web-enabled devices should, at a minimum, support the DDR Core Vocabulary as defined in this document.

Enable the WSDM Event Format using the Generic Log Adapter
Abdi Salahshour and Jane Fang, IBM developerWorks

This article explains how Common Base Events can be converted into WEF events using IBM and Apache Muse WEF libraries. In 2005, the Common Base Event specification was submitted to the OASIS WSDM Technical Committee, which adopted the Common Base Event as a base for the WSDM Event Format (WEF). If you've already adopted the Common Base Event format but want to transform native log events further into WEF events, this article describes the details of the mapping between the Common Base Event and WEF and shows you how into turn a Common Base Event adapter into a WEF adapter. Events are an external, visible manifestation of all system operations—they represent the onset, evolution, and conclusion of processes. The situation represented by an event may have only local relevance or may provide a key piece of information required by a high-level environment management system. The event, which encapsulates data sent as the result of an occurrence, or situation, represents the very foundation on which these complex systems communicate. The Common Base Event—which uses a consistent and common format to represent an event produced during the operation of an IT system -- facilitates effective intercommunication among disparate components that support logging, management, problem determination, autonomic computing, and on demand business functions in an enterprise. The goal of defining the Common Base Event format is to ensure the accuracy, improve the detail, and standardize the format of events to assist in designing robust, manageable, and deterministic systems. Quality event data leads to accurate management of the enterprise... The Common Base Event definition, besides providing definitions and requirements for the basic meta-data, ensures completeness of the data by providing properties to publish the following information: (1) The identification of the component that is reporting the situation; (2) The identification of the component that is affected by the situation—which may be the same as the component that is reporting the situation; (3) A common description of the situation that occurred; (4) Content that can be used to correlate situations.


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

Headlines

Sponsors