Cover Pages: XML Daily Newslink: Tuesday, 26 October 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:
Microsoft Corporation http://www.microsoft.com

Headlines

W3C First Public Working Draft: File API, Directories and System
IETF Charters New Applications Area Working Group
ODRL V2.0: XML Encoding
Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
Updates for Eight HTML5 Working Drafts
XML 2010: What's New in DocBook Version 5?
Ping Identity, RSA Team on Cloud Authentication
Protocol Positioning from Field to Cloud

W3C First Public Working Draft: File API, Directories and System
Eric Uhrhane (ed), W3C Technical Report

The W3C WebApps Working Group has released a First Public Working Draft of the specification File API: Directories and System, intended to be advanced to Recommendation status. This specification defines an API to navigate file system hierarchies, and defines a means by which a user agent may expose sandboxed sections of a user's local filesystem to web applications. It builds upon the "File Writer API" Working Draft, which in turn depends upon the "FILE-API" specification, each adding a different kind of functionality. Updated Working Drafts for the two related specifications have been published by the WebApps Working Group. The Working Group has also updated the Widget Requirements draft. where a 'widget' is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device.

Use cases for the File API: Directories and System specification include: "(1) Persistent uploader: When a file or directory is selected for upload, it copies it into a local sandbox and uploads a chunk at a time; it can restart uploads after browser crashes, network interruptions, etc. (2) Video game or other application with lots of media assets: It downloads one or several large tarballs, and expands them locally into a directory structure, where the same download should work on any operating system; it can manage prefetching just the next-to-be-needed assets in the background, so going to the next game level or activating a new feature doesn't require waiting for a download. (3) Audio/Photo editor with offline access or local cache for speed: The data blobs are potentially quite large, and are read-write; it may want to do partial writes to files, ovewriting just the ID3/EXIF tags, for example; edited files should be accessable by client-side applications (iTunes, Picasa). (4) Offline video viewer: It downloads large files (> 1GB) for later viewing, with support for efficient seek and streaming; it must be able to hand a URI to the video tag and should enable access to partly-downloaded files. (5) Offline Web Mail Client: Downloads attachments and stores them locally; caches user-selected attachments for later upload; triggers the UA's download manager just as if talking to a server; uploads an email with attachments as a multipart post, rather than sending a file at a time in an XHR..."

The File API: Writer specification "defines an API for writing to files from web applications. This API is designed to be used in conjunction with, and depends on definitions in, other APIs and elements on the web platform. This API includes a BlobBuilder interface, which enables one to build a Blob from a String, and a FileSaver interface, which provides methods to write a Blob to a file, with an event model to monitor the progress of those writes. It features a FileWriter interface, which expands on FileSaver to add a richer set of output options, and a FileWriterSync interface, which provides methods to write and modify files synchronously in a Web Worker."

The File API specification, edited by representatives of the Mozilla Corporation, "provides an API for representing file objects in web applications, as well as programmatically selecting them and accessing their data. The File interface represents file data typically obtained from the underlying file system, and the Blob (Binary Large Object) represents raw data. File or Blob reads should happen asynchronously on the main thread, with an optional synchronous API used within threaded web applications. An asynchronous API for reading files prevents blocking and UI 'freezing' on a user agent's main thread. This specification defines an asynchronous API based on an event model to read and access a File or Blob's data. A FileReader object provides asynchronous read methods to access that file's data through event handler attributes and the firing of events. The use of events and event handlers allows separate code blocks the ability to monitor the progress of the read (which is particularly useful for remote drives or mounted drives, where file access performance may vary from local drives) and error conditions that may arise during reading of a file..."

IETF Charters New Applications Area Working Group
IESG Secretary, Announcement for IETF

The Internet Engineering Steering Group (IESG) announced the formation of a new IETF Applications Area Working Group. "The IETF Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group....

Thus, the Applications Area Working Group (APPSAWG) will serve as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the Working Group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion.

Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies. (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and metadata. (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, HTTP, internationalization, language tags, MIME, URIs and XML.

When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others, for example. There may be no existing related Working Group that is willing to recharter to take on the candidate work, and the document doesn't justify the formation of a new working group... Or, the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization)...

ODRL V2.0: XML Encoding
Renato Iannella (ed), ODRL Initiative Working Draft

Members of the ODRL Initiative have published a second public Working Draft of the ODRL V2.0 XML Encoding Specification document produced by the ODRL Version 2.0 Working Group. "The ODRL Initiative publishes a Working Draft for review by working group members and other interested parties. The ODRL Version 2.0 Working Group expects to advance this document to a Draft Specification once the Working Group is satisfied the encoding has broad consensus and demonstrated at least two interoperable implementations.

The Open Digital Rights Language (ODRL) Initiative is "an international effort aimed at developing and promoting an open standard for policy expressions. ODRL provides flexible and interoperable mechanisms to support transparent and innovative use of digital content in publishing, distribution and consumption of digital media across all sectors and communities."

Specification Overview: "The ODRL Version 2.0 language is defined by the ODRL Model and ODRL Common Vocabulary in an abstract manner to capture the semantics of the expression, without any specific syntax and/or encoding method. This document describes how to encode both the Model and Common Vocabulary, including any community developed Profiles, using the XML syntax with XML Schema and XML Schema Datatypes... As much as possible, each of the core entities (UML Classes) from the ODRL Model will be represented by an XML element of the same name. Additionally, each entity attribute will be represented as an XML attribute of the parent element. The fixed values defined in the Model are represented as enumerated types. Cardinalities are also represented with XML Schema occurrence rules...

Examples: (1) The W3C Privacy Rulesets Editor's Draft has been developed by the W3C Device APIs and Policy Working Group as a scheme for defining privacy rulesets: bundles of user privacy preferences that can be conveyed together with user data in the context of a web site or application interaction. The document defines three Privacy Elements with a number of attributes... (2) The Open Data Commons provides a number of licenses for the sharing of open databases. One example is the Open Database License (ODbL) v1.0 which enables you to "share, create, and adapt" the database as long as you "attribute, share-a-like, and keep open" the outcomes; we show how to represent that license in ODRL... (3) The Extensible Messaging and Presence Protocol provides a real-time transport mechanism for structured XML information which may be useful for transporting ODRL information over XMPP. ODRL XML expressions may be sent via the XML message stanza defined in XMPP Core using either of the following: (A) Directly from the sender to a single recipient or a list of recipients, using Extended Stanza Addressing, or (B) Published to a list of subscribers via Publish-Subscribe..."

See also: earlier ODRL references

Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear (eds), IETF Internet Draft

IETF has published an initial level -00 Internet Draft for Application Bridging for Federated Access Beyond Web (ABFAB) Architecture. Document abstract: "Over the last decade a substantial amount of work has occurred in the space of federated authentication and authorization. Most of this effort has focused on two common use cases: network and web-based access, with few common building blocks within the architecture. This memo describes an architecture that makes use of extensions to the commonly used mechanisms for both federated and non-federated authentication and authorization, including Radius/Diameter, GSS/GS2, and SAML, to primarily address non-web based authentication, in a that will scale to large numbers of federations..."

From the Introduction: "The Internet makes uses of numerous authentication methods to grant access to various resources. These mechanisms have been generalized and scaled over the last decade through mechanisms such as GS2, Security Assertion Markup Language (SAML), Radius, and Diameter. So-called "federated" access has evolved over the last decade between web servers through such standards as SAML, OpenID, and OAUTH, allowing entire domains of individuals to be authorized for resources. The key scaling points that have been addressed are the following: (1) An Internet service need not copy manually authentication information from a domain to allow for authentication and authorization. (2) Individual users are able to make use of a single credential to authenticate to such services.

As the number of such federated services has proliferated, however, the role of the individual has become ambiguous in certain circumstances. For example, a school might provide online access to grades to a parent who is also a teacher. She must clearly distinguish her role upon access. After all, she is probably not allowed to edit her own child's grades.

Similarly, as the number of federations proliferates, it becomes increasingly difficult to discover which identity provider a user is associated with. This is true for both the web and non-web case, but particularly acute for the latter ans many non-web authentication systems are not semantically rich enough on their own to allow for such ambiguities. For instance, in the case of an email provider, the use of SMTP and IMAP protocols does not on its own provide for a way to select a federation. However, the building blocks do exist to add this functionality..."

Updates for Eight HTML5 Working Drafts
Staff, W3C Announcement

The W3C HTML Working Group has released eight related documents for public review. First, there are new Working Drafts of the HTML5 specification, the accompanying explanatory document HTML5 differences from HTML4, and the related non-normative reference document 'HTML: The Markup Language.'

New Working Drafts are available for the specifications 'HTML+RDFa 1.1' and HTML Microdata, which define mechanisms for embedding machine-readable data in HTML documents, and the specification HTML Canvas 2D Context, which defines a 2D immediate-mode graphics API for use with the HTML5 'canvas' element. The specification 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.

HTML5: Techniques for Providing Useful Text Alternatives documents 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.

Polyglot Markup: HTML-Compatible XHTML Documents, edited by Eliot Graff, provides 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 document that is a stream of bytes that parses into identical document trees (with the exception of the xmlns attribute on the root element) when processed as HTML and when processed as XML. Polyglot markup that meets a well defined set of constraints is 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..."

XML 2010: What's New in DocBook Version 5?
Norm Walsh, Blog

"I spoke last week at XML 2010. In particular, I spoke about what's new in DocBook Version 5. Herewith, a few thoughts on XML 2010 and my slides. The theme of the conference this year, 'eMedia Revolution', seemed like the sort of thing that ought to be very popular. Certainly, there are lots of interesting things being created and discussed in the realm of eMedia. Publishing for pads, tabs, and phones seems to be all the rage. I don't think every current trend is a good idea, but that's the sort of thing I was hoping to hear discussed...

Any discussion about eMedia publishing involves, at least a tangentially, a discussion of modular content and reuse. That's the primary focus of the work that the DocBook Technical Committee is doing on DocBook V5.1, so I thought it would be good to pitch a presentation about our current progress...

DocBook is an XML vocabulary for writing. It is particularly well-suited to books and papers about computer software and hardware, though it is by no means limited to them. DocBook has been actively maintained for more than a decade. It was originally developed by the Davenport Group. It is now being developed by an OASIS Technical Committee. DocBook was an SGML DTD for many years, then an XML DTD, and now officially a RELAX NG Grammar.

What has changed recently? Uniform info elements; Info elements in more contexts; Better constraint checking, e.g., titles inside/outside info; Simple co-constraints; Untangled tables; Ability to use a few real datatypes; Extra-grammatical constraints—Schematron rules; Hugely simplified customization... I talked a little bit about DTDs and parameter entities. There aren't any in DocBook V5. Of course, there are RELAX NG patterns, but they don't come with the same level of complexity... The DocBook TC is investigating the general problems of transclusion, where the focus is on transclusion of DocBook documents, but the problem is clearly much broader..."

See also: the OASIS DocBook TC

Ping Identity, RSA Team on Cloud Authentication
Vance McCarthy, Integration Developer News

"Security and authentication vendor Ping Identity is working with RSA to improve authentication services for cloud computing. Ping has joined RSA's Secured Partner Program and certified interoperability between its PingFederate and RSA SecurID authentication.

PingFederate Integration Kit for RSA SecurID lets organizations use PingFederate Cloud SSO (single sign-on) and RSA SecurID authentication in an integrated way that helps them improve security, saves money and increases the usability of the application...

PingFederate is an Internet identity security platform for a variety of Internet-facing identity management, delivering features that can solve the password problem for Internet applications, improve workforce productivity,reduce administrative overhead, and improve security and compliance.

PingFederate performs three critical security functions: (1) Internet Single Sign-On (SSO): Users sign on once to their corporate network, then PingFederate securely communicates their identities to internal and external web-based applications, including the cloud. (2) Internet User Account Management: PingFederate integrates with corporate directories to automatically create, update and disable user accounts for web and cloud-based applications throughout the user's lifecycle. (3) Universal Token Translation: PingFederate's Security Token Service translates security tokens from one format to another, streamlining the process of sharing user identities between disparate security domains... When a user with an RSA SecurID software or hardware token tries to access a cloud application, PingFederate generates a SAML or WS-Federation assertion and sends it directly to the service provider through a secure connection..."

Protocol Positioning from Field to Cloud
Nino Kurtalj, AutomatedBuildings.com

"Regardless of electrical interface, there are three media access methods used today [in building automation systems]: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) (Ethernet, LonTalk, CAN), Token passing (BACnet) and Master-Slave (Modbus). Today, we are not really thinking about what will be used at the physical level, copper or fiber. Generally, we can assume that the Internet/Intranet itself is media. [But] the variety of protocols that we have today with their complexity and purpose makes it impossible to integrate them all unconditionally into a single seamless integrated system.

For years we listened to stories about interoperability and interchangeability, but in reality most manufacturers are trying to find the way to close the system, so they can control the automation and control structure in the building forever. Even when they are using open protocols like LonWorks or BACnet they are establishing a BMS structure which is able to accept other devices and protocols but could not be exchanged with the other BMS system. We are living in an era of proprietary systems based on top of open protocols...

Generally, we can divide it into two platforms: application protocol platform and technology protocol platform. Service oriented architecture with web services represents basically the application protocol platform. We can assume there are four general layers: (1) Integration platforms: JSON, XML structures, oBix, OPC UA, BrightCore; (2) Network protocols: BACnet, LonWorks, Modbus, SNMP, N1; (3) Field protocols: LonWorks, BACnet, Modbus, N2, KNX, DALI, M-bus, SMI; (4) Edge protocols: 4-20mA, 0-10V, digitals, ZigBee, Z-wawe...

Cloud computing is at the beginning, and everyone is trying to address cloud-based services. Software as a Service will prevail for sure in the future. Everyone will offer their scope of web services, APIs and even cloud computing development environment, trying to dominate by providing fast application development and assuring big customer base. However, this will not be an easy transformation... Everyone will be forced to open up all network layers, and we will achieve at the speed of light full-scale interoperability and manageability."


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

Headlines

Sponsors