Cover Pages: XML Daily Newslink: Monday, 28 June 2010

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:
Oracle Corporation http://www.oracle.com

Headlines

OASIS Members Propose Privacy Management Reference Model (PMRM) TC
New W3C RIF Standard Supports Data Integration and Enterprise Agility
A New Header For Metadata Exchange
W3C HTML Working Group Releases First Public Working Drafts
ODF and OOXML Translation: Working Draft 2 of ISO Technical Report
IETF/ITU-T Clarify OAM (Operations, Administration, and Maintenance)
U.S. Outlines Security Strategy for Online Identity

OASIS Members Propose Privacy Management Reference Model (PMRM) TC
Staff, OASIS Announcement

OASIS has published the text of a proposed charter for a new 'Privacy Management Reference Model (PMRM) Technical Committee'. The principal purpose of the PMRM TC will be to develop and articulate a Privacy Management Reference Model that describes a set of broadly-applicable data privacy and security requirements and a set of implementable Services and interactions for fulfilling those requirements.... This TC will operate under the Non-Assertion Mode of the OASIS IPR Policy. The charter proposal has support from representatives of CA Technologies, ISTPA, NIST, American Bar Association, and WidePoint Corporation, together with five individual members.

As proposed, the OASIS PMRM TC would: (1) Define a set of operationally- focused privacy requirements which can serve as a reference for evaluating options for designing and implementing operational privacy controls. These requirements will constitute a useful working set of 'privacy guidelines', which can both serve as general guidance, and as a feature set against which the PMRM and any implementation can be tested. (2) Define a structured format for describing privacy management Services, and identify categories of functions that may be used in defining and executing the Services. (3) Define a set of privacy management Services to support and implement the privacy requirements at a functional level... (4) Establish an explicit relationship between security requirements and supporting security services (such as confidentiality, integrity and availability services) and the privacy management Services. Security services and standards are essential to secure Personal Information; therefore, each specific privacy management Service is expected to have its own security service requirements.

For purposes of this project, from a business and operational perspective, 'data privacy' is defined to mean the assured, proper, and consistent collection, storage, processing, transmission, use, sharing, trans border transfer, retention and disposition of Personal Information (PI) throughout its life cycle, consistent with data protection principles, privacy and security policy requirements, and the preferences of the individual, where applicable...

The purpose of the OASIS Privacy Management Reference Model is to aid in the design and implementation of operational privacy and security management systems. The Reference Model is intended to serve as a guideline or template for developing operational solutions to privacy issues, as an analytical tool for assessing the completeness of proposed solutions, and as the basis for establishing categories and groupings of privacy management controls. The Reference Model will serve as an evaluation framework for implementations, but will not itself be an implementation. It is intended to be used as a tool or basis for development of further implementations and standards, which either currently exist or would be developed independently..."

New W3C RIF Standard Supports Data Integration and Enterprise Agility
Staff, W3C Announcement

On June 22, 2010, the World Wide Web Consortium (W3C) announced the publication of a new standard for building rule systems on the Web. "Declarative rules allow integration and transformation of data from multiple sources in a distributed, transparent and scalable manner. The new standard, called Rule Interchange Format (RIF), was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. The RIF Working Group was chartered to create a standard for exchanging rules among rule systems, in particular among Web rule engines. The RIF Working Group has focused on two kinds of dialects: logic-based dialects and dialects for rules with actions... The family of RIF dialects is intended to be uniform and extensible. RIF uniformity means that dialects are expected to share as much as possible of the existing syntactic and semantic apparatus. Extensibility here means that it should be possible for motivated experts to define a new RIF dialect as a syntactic extension to an existing RIF dialect, with new elements corresponding to desired additional functionality.

The specification includes six new standards documents. (1) RIF Core Dialect "specifies RIF-Core, a common subset of RIF-BLD and RIF-PRD based on RIF-DTB 1.0. The RIF-Core presentation syntax and semantics are specified by restriction in two different ways. First, RIF-Core is specified by restricting the syntax and semantics of RIF-BLD, and second, by restricting RIF-PRD. The XML serialization syntax of RIF-Core is specified by a mapping from the presentation syntax. A normative XML schema is also provided." (2) RIF Basic Logic Dialect "specifies the Basic Logic Dialect, RIF-BLD, a format that allows logic rules to be exchanged between rule systems. The RIF-BLD presentation syntax and semantics are specified both directly and as specializations of the RIF Framework for Logic Dialects, or RIF-FLD." (3) RIF Production Rule Dialect "specifies the production rule dialect of the W3C rule interchange format (RIF-PRD), a standard XML serialization format for production rule languages."

Also, (4) RIF Framework for Logic Dialects "defines a general RIF Framework for Logic Dialects (RIF-FLD). The framework describes mechanisms for specifying the syntax and semantics of logic RIF dialects through a number of generic concepts such as signatures, symbol spaces, semantic structures, and so on. The actual dialects should specialize this framework to produce their syntaxes and semantics." (5) RIF Datatypes and Built-Ins 1.0, "borrowing heavily from XQuery and XPath for a set of basic operations, specifies a list of datatypes, built-in functions and built-in predicates expected to be supported by RIF dialects such as the RIF Core Dialect, the RIF Basic Logic Dialect, and the RIF Production Rules Dialect. Each dialect supporting a superset or subset of the datatypes, built-in functions and built-in predicates defined here shall specify these additions or restrictions.... (6) RIF RDF and OWL Compatibility "specifies the interoperation between RIF and the data and ontology languages RDF, RDF Schema, and OWL."

Along with these standards, W3C has also published five related documents: RIF Overview, RIF Test Cases, OWL 2 RL in RIF, RIF Combination with XML Data, and RIF In RDF. The RIF Working Group is also preparing a primer and a revision of its outdated document Use Cases and Requirements.

See also: the RIF FAQ document

A New Header For Metadata Exchange
Moon-Sang Lee and Jung-Lok Yu (eds), IETF Internet Draft

An initial level -00 Standards Track IETF Internet Draft has been published for review: A New Header For Metadata Exchange. This specification "provides a mechanism by which web servers can provide metadata of a web resource which is indicated by a URL. The web client like web browser can use this metadata to filter out unwanted web resource or link to itself. In addition, the web client can take advantage of such metadata to provide high-level services like displaying additional information about the web resource without downloading it. We expect this mechanism to enable quick access to metadata of any web resource from any web client reduces overall web traffic remarkably."

Background: "The URL enables access to web resource in a uniform way. A web client sends a request to a URL of a web resource which may be an html page, an audio/video file, a proprietary document file, or even a web service endpoint. A web server which is presented as a part of the URL responds with the requested web resource. Small-sized HTML pages had dominated traditional web sites and small- sized photos at most. However, with the evolving of the Web, large media files and streaming services are overwhelming the Web. There are millions of large photos taken by DSLR, mp3 files with high bit ratio, and user-generated video files. A media file is encoded in its own format and cannot be understood by a client program until it is downloaded and its header is verified, which incurs excessive data traffic. If a client program can get metadata of a web resource beforehand, it can induce minimal traffic by driving user to select a necessary resource or automatically filtering out unnecessary resources.

This proposal for extending the HTTP header enables acquiring metadata of web resource with least modifications to HTTP 1.1. This extension specifies optional header fields which web clients and servers may present to each other in its request and response messages. The extended header fields are defined as below: (1) HTTP Request Header Extension: Resource-Meta: Exclusive | Inclusive | None; (2) HTTP Response Header Extension: (1) Resource-Meta-Data: Quoted-String; (b) Resource-Meta-Location: URL... A web client may or may not specify the Resource-Meta header field. If it does not specify the header field, the protocol operates in the same way as HTTP 1.1. If it does, the protocol behaves differently according to the value of Resource-Meta header field. The Resource-Meta header may have one of three values: Exclusive (it requests only metadata of web resource, specified by a URL), Inclusive (it requests both of web resource and its metadata, specified by a URL), or None (it is the same as not specifying the Resource-Meta header field).

There are various resources in the Web and their formats are hard to be standardized in one single format. In addition, this proposal is not for metadata representation but for metadata transfer. Therefore, it is good to respect commodity standards like id3 tag of mp3 format and to follow the internet media type, per RFC 2046. Or, it is also good to follow the Ontology for Media Resource by Media Annotation Working Group in W3C. The only restriction is that all metadata should be presented in XML whether it is embedded directly in the response header or is provided through a URL indicated in the response header...

W3C HTML Working Group Releases First Public Working Drafts
Staff, W3C Announcement

Members of the W3C HTML Working Group have published eight documents for review, including two First Public Working Drafts. The new specification HTML5: Techniques for Providing Useful Text Alternatives presents author conformance requirements for use of the 'alt' attribute in HTML5 and best practice guidance for authors of HTML documents on providing text alternatives for images. Text alternatives are a primary way of making visual information accessible, because they can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. Providing text alternatives allows the information to be rendered in a variety of ways by a variety of user agents. For example, a person who cannot see a picture can have the text alternative read aloud using synthesized speech.

The document Polyglot Markup: HTML-Compatible XHTML Documents summarizes design guidelines for authors who wish their XHTML or HTML documents to validate on either HTML or XML parsers, assuming the parsers to be HTML5-compliant. A document that uses polyglot markup is an HTML5 document which is at the same time an XML document and an HTML document, and which meets a well defined set of constraints. Polyglot markup that meets these constraints as interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification. Polyglot markup uses a specific doctype, namespace declarations, and a specific case—normally lower case but occasionally camel case—for element and attribute names. Polyglot markup uses lower case for certain attribute values. Further constraints include those on empty elements, named entity references, and the use of scripts and style.

Updated Working Drafts have also been published for the HTML5 specification (HTML5: A Vocabulary and Associated APIs for HTML and XHTML), for the accompanying explanatory document HTML5 Differences from HTML4, and the related non-normative reference HTML: The Markup Language. HTML5 defines the fifth major revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.

Finally, updated Working Drafts have been releases for the following specifications: (1) HTML+RDFa 1.1: Support for RDFa in HTML4 and HTML5, defines rules and guidelines for adapting the RDFa Core 1.1 specification for use in HTML5 and XHTML5. The rules defined in this specification not only apply to HTML5 documents in non-XML and XML mode, but also to HTML4 and XHTML documents interpreted through the HTML5 parsing rules. (2) HTML Microdata, which defines the HTML microdata mechanism. This mechanism allows machine-readable data to be embedded in HTML documents in an easy-to-write manner, with an unambiguous parsing model. It is compatible with numerous other data formats including RDF and JSON. (3) Canvas 2D Context, which defines a 2D immediate-mode graphics API for use with the HTML5 'canvas' markup element..."

See also: the W3C HTML Working Group

ODF and OOXML Translation: Working Draft 2 of ISO Technical Report
Rick Jelliffe, O'Reilly Technical

ISO/IEC JTC1 SC34 WG5 members have released the second draft of the Technical Report comparing ODF and OOXML. It is up to 126 pages now, and much more fleshed out than the first draft. Title: Working Draft 2 for TR 29166, Information technology—Document description and Processing Languages—OpenDocument Format / Office Open XML Translation - Guidelines. This document has been "circulated to the SC 34/WG 5 members for review and comment. The Technical Report, TR 29166, will reach the PDTR status in November 2010 after the next WG 5 meeting in Tokyo. The project editors would like to get WG 5 members' feedback on the current working draft (WD2) to improve the document."

One of the issues that came out during the intense lobbying of 2007/2008 was that a lot of work needed to be done comparing the formats before anyone could really justify dogmatic statements that ODF could already do everything needed by OOXML on the one hand, or that ODF's rationale and approach was so different and incomplete that it was and always would be completely unsuitable on the other. What we had was working theories and a mix of prejudice and expertise. So now after a couple of years effort, we are starting to get a better shape of things...

So now after a couple of years effort, we are starting to get a better shape of things. I have made a little scorecard, based on a quick count of the comparison of features and functions in section 6 of the report. Combining the word processing and metadata counts: (1) Features or functions whose translatability (between ODF and OOXML) is rated High: 33. (2) Features or functions whose translatability is rated Medium: 50. (3) Features or functions with low translatability, from lack of support in OOXML: 16. (4) Features or functions with low translatability, from lack of support in ODF: 11... So that gives us about 15 percent of the broad features counted as having low translatability...

These differences reflect not just file format capabilities, but reflect the different capabilities of the software which implements each format natively: Word and OpenOffice... One opportunity that this report may give us is to be able to write a kind of validator that tells users when their document has features that may not survive round-tripping well..."

IETF/ITU-T Clarify OAM (Operations, Administration, and Maintenance)
Loa Andersson,Huub van Helvoort, Ron Bonica (et al., eds) IETF Internet Draft

The Internet Engineering Steering Group (IESG) announced receipt of a request to consider publication of The OAM Acronym Soup as an IETF Informational RFC. This document is a product of a joint effort by the Internet Engineering Task Force (IETF) and International Telecommunication Union Telecommunication Standardization Sector (ITU-T) to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action; please send substantive comments to the IETF mailing lists by 2010-07-09. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call.

Background: "The acronym OAM is frequently used in the data and telecommunication industry. One would assume that something that is so widely used is very clearly defined. However a closer look reveals some points that need to be clarified... Misunderstanding of an acronym may lead to incorrect specification or implementation which may, in turn, open up security concerns with protocols or deployed networks. Clarifying the meaning of OAM is, therefore, a benefit for future stability of specifications.

The components of the OAM acronym (and provisioning) "are defined as follows: (1) Operations: Operation activities are undertaken to keep the network (and the services that the network provides) up and running. It includes monitoring the network and finding problems. Ideally these problems should be found before users are affected. (2) Administration: Administration activities involve keeping track of resources in the network and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control...

(3) Maintenance: Maintenance activities are focused on facilitating repairs and upgrades - for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more effectively, e.g. adjusting device configuration and parameters. (4) Provisioning: Provisioning activities involve configuring resources in the network to support the offered services. This might include setting up the network so that a new customer can receive an Internet access service."

U.S. Outlines Security Strategy for Online Identity
Brian Prince, eWEEK

"The U.S. White House has published a draft of a strategy designed to make the concept of trusted identities and authentication more of a reality in the digital world. In a 39-page document (National Strategy for Trusted Identities in Cyberspace: Creating Options for Enhanced Online Security and Privacy), the White House promotes what it calls the Identity Ecosystem, an interoperable environment where individuals, organizations and devices can trust each other because authoritative sources establish and authenticate their digital identities.

The proposed ecosystem will consist of three main layers: a governance layer that establishes the rules of the environment; a management layer that applies and enforces the rules of the ecosystem; and the execution layer that conducts transactions in accordance with the rules. The U.S. Department of Homeland Security will be collecting comments from the public on the document until July 19, 2010..."

From the document's Executive Summary: "Privacy protection and voluntary participation are pillars of the Identity Ecosystem. The Identity Ecosystem protects anonymous parties by keeping their identity a secret and sharing only the information necessary to complete the transaction. For example, the Identity Ecosystem allows an individual to provide age without releasing birth date, name, address, or other identifying data. At the other end of the spectrum, the Identity Ecosystem supports transactions that require high assurance of a participant's identity. The Identity Ecosystem reduces the risk of exploitation of information by unauthorized access through more robust access control techniques. Finally, participation in the Identity Ecosystem is voluntary for both organizations and individuals...

Interoperability and privacy protection combine to create a user-centric Identity Ecosystem. Usercentricity will allow individuals to select the interoperable credential appropriate for the transaction. Through the creation and adoption of privacy-enhancing policies and standards, individuals will have the ability to transmit no more than the amount of information necessary for the transaction, unless they choose otherwise. In addition, such standards will inhibit the linking of an individual's transactions and credential use by service providers. Individuals will have more confidence that they exchange information with the appropriate parties, securely transmit that information, and have the information protected in accordance with privacy best practices..."


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

Headlines

Sponsors