This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation http://www.microsoft.com
- Ecma International Approves New Patent Policy Document
- Constrained Application Protocol (CoAP) Feature Analysis
- W3C CR Publication for 'Web Security Context: User Interface Guidelines'
- IETF Definition of Working Group Document States
- Service-Oriented Models for Educational Resource Federations
- Preservation Planning: From TIFF to JPEG 2000?
- SCA Components with Spring: Advanced Techniques Using Apache Tuscany
- 3D Media and the Semantic Web
Ecma International Approves New Patent Policy Document
Staff, Ecma Announcement
"The Ecma General Assembly held on December 3, 2009 in Mountain View, CA, USA has unanimously approved a new version of the Ecma Patent policy called 'Code of Conduct in Patent Matters'. The new policy has been modeled after the joint Patent Policy of ITU/ISO/IEC, but basic concepts of the previous Ecma patent policy were retained...
Ecma created its first policy on patents in 1963. Ecma has periodically reviewed and revised its patent policy to provide additional clarification and to address new issues. Ecma believes that these changes will provide a more effective framework for addressing the issues that arise when patented technology is included in Ecma international standards.
The default option for necessary patented technology to be incorporated into an Ecma International standard is still RAND (Reasonable and non-discriminatory), but the policy also allows a RF (royalty free and other RAND terms) option. The Policy also clarifies that different patents of a patent holder may be subject to different licensing statement options and under what circumstances a patent holder may re-designate a previously committed license statement option. It further clarifies the extent to which a patent holder's licensing commitment will also apply to revised versions of an Ecma standard...
The 'Patent Statement and Licensing Declaration Form for an Ecma International Standard' presents three checkboxes for terms. In summary: (1) "The Patent Holder is prepared to grant a free of charge license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and under other reasonable terms and conditions to make, use, and sell implementations of the above standard... (2) The Patent Holder is prepared to grant a license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and on reasonable terms and conditions to make, use and sell implementations... (3) The Patent Holder is not prepared to grant licenses in accordance with provisions of either 1 or 2 above, [in which case], the following information must be provided as part of this declaration: [i] granted patent number or patent application number, if pending; [ii] an indication of which portions of the above standard are affected; [iii] a description of the patent claims covering the above standard..."
See also: the IPR declaration form
Constrained Application Protocol (CoAP) Feature Analysis
M. Stuber, D. Sturek, B. Frank, R. Kelsey; IETF Internet Draft
In initial version -00 IETF Internet Draft has been published for Constrained Application Protocol (CoAP) Feature Analysis. The document considers the requirements and resulting features needed for the design of the Constrained Application Protocol (CoAP). Starting from requirements for energy and building automation applications, the basic features are identified along with an analysis of possible realizations. The goal of the document is to provide a basis for protocol design and related discussion.
The use of web services on the Internet has become ubiquitous in most applications, and depends on the basic REST architecture of the web. The proposed Constrained RESTful Environments (CoRE) working group aims at extending the REST architecture to a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). One of the main goals of CoRE is to design a generic RESTful protocol for the special requirements of this constrained environment, especially considering energy and building automation applications. The result of this work should be a Constrained Application Protocol (CoAP) which easily traslates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity.
Document Section 3 ('Applicability') examines the applicability of the CoAP features for energy, building automation and other macine-to-machine (M2M) applications... Although many of the embedded control solutions for building automation make use of industry-specific application protocols like BACnet over IP, there is a growing use of web services in building monitoring, remote control and IT integration. The OASIS oBIX standard is one example of the use of web services for the monitoring and interconnection of heterogeneous building systems. Several of the CoAP requirements have been [taken into consideration]. The resulting features should allow for peer-to-peer interactions as well as node-server request/response and push interfactions for monitoring and some control purposes. For building automation control with very strict timing requirements using e.g. multicast, further features may be required on top of CoAP.
CoAP is proposed as a transport agnostic extension of REST for deployment in confined computing environments. The intent is to align CoAP with HTTP wherever possible to leverage the web services computing environment already in place. Whereas REST envisions just four primitives (READ, SET, CREATE and DESTROY), CoAP proposes to extend this paradigm with a NOTIFY primitive to enable publish/subscribe along with a DISCOVER primitive to support multicast discovery of services denoted by URL. The main architectural difference between READ and the new discovery primitive is the requirement to not respond if the URL is not present on a local device..."
See also: Smart Energy Requiements for 6LowApp
W3C CR Publication for 'Web Security Context: User Interface Guidelines'
Thomas Roessler and Anil Saldhana (eds), W3C Technical Report
Members of the W3C Web Security Context Working Group now invite implementation of the Candidate Recommendation specification Web Security Context: User Interface Guidelines. This specification "deals with the trust decisions that users must make online, and with ways to support them in making safe and informed decisions where possible. It specifies user interactions with a goal toward making security usable, based on known best practice in this area...
In order to achieve the target goals, this specification includes recommendations on the presentation of identity information by user agents (Identity Signal). We also include recommendations on conveying error situations in security protocols. The error handling recommendations both minimize the trust decisions left to users, and represent known best practice in inducing users toward safe behavior where they have to make these decisions. To complement the interaction and decision related parts of this specification, the document addresses the question of how the communication of context information needed to make decisions can be made more robust against attacks... Most sections assume the audience has a certain level of understanding of the core PKI (Public Key Infrastructure) technologies as used on the Web.
Part of a Working Group's activities is developing code and test suites. We are targetting three types of testing of our recommendations: functional testing, robustness testing, and usability testing... All test development and testing is iterative. The recommendations may need to be modified on the basis of all three types of testing. Test development starts when work on the specification starts. Test planning will include guidelines for developing tests. Test suites are typically developed when the specifications are in a reasonably stable state, such as the first full public working draft. Test development will include test execution instructions... Robustness testing will verify that the recommendations are robust against spoofing attacks...
This specification comes with two companion documents: Web Security Experience, Indicators and Trust: Scope and Use Cases documents the initial assumptions about the scope of this specification. It also includes an initial set of use cases the Working Group discussed. Web User Interaction: Threat Trees documents the Working Group's initial threat analysis. This document is based on current best practices in deployed user agents, and covers the use cases and threats in those documents to that extent..."
IETF Definition of Working Group Document States
Ed Juskevicius (ed), IETF Internet Draft
This level -00 document Definition of Working Group Document States contains definitions for all of the different states that IETF documents (viz., Internet-Drafts) may experience with an IETF working group. The first state occurs when an I-D is submitted for consideration as a working group item, and the last state is either when the I-D is sent to the IESG for publication, or declared as 'dead'...
A desired outcome of this initiative is to facilitate the coding of front-end extensions to the IETF I-D Tracker tool, to allow WG Chairs and other members of the community to monitor the status of I-Ds as they progress through IETF working groups. In order for the I-D Tracker to reflect WG document status information, new WG document states and sub-state 'annotation tags' need to be defined, agreed, and then coded into the front-end of the tool.
Document Section 3.1 defines the possible states that could apply to an I-D that has been submitted to an IETF working group. Section 3.2 maps those states into a first draft state diagram. Section 3.3 defines additional terms to describe various WG Document sub-states... The suggested WG Document States are: Candidate WG Document, Active WG Document, Not a WG Document, Parked WG Document, In WG Last Call, Waiting for WG Document Shepherd Write-Up, Submitted to IESG for Publication, and Dead WG Document...
In addition to identifying the state that each WG Document is in, it would be informative to indicate associated sub-states or conditions which may affect each WG Document: 'Awaiting Cross-Area Review,' 'Awaiting MIB Doctor Review,' 'Awaiting Security Review,' 'Awaiting Other Reviews,' 'Awaiting Merge with other Document,' 'Doc Shepherd Follow-up,' 'Editor Needed,' 'Held due to Dependency on other Document,' 'Held due to IESG concerns on this Document,' 'Revised ID Needed - based on WG consensus,' 'Revised ID Needed - after on WG last call,' 'Other - see Comment Log.' In addition to the sub-state annotation tags defined in section 3.3.1, the intended maturity level of every WG Document should also be tracked, per RFC 2026: 'Experimental', 'Informational', 'Best Current Practice', 'Proposed Standard', 'Draft Standard', 'Full Standard', and 'Historic'..."
Service-Oriented Models for Educational Resource Federations
Daniel R. Rehak, Nick Nicholas, Nigel Ward; D-Lib Magazine
"Education resources and learning objects are stored and maintained in a multitude of collections and repositories. Having multiple, distributed sources makes resource discovery, access and use overly complex for most users. Resource federations provide a single point of discovery and access to a larger number of resources. In this paper we present a service-oriented model for a scalable infrastructure that supports resource federations for educational content, including support for publishing, federated search, federated metadata registries, and federations of federations.
Several organizations have formed their own educational resource federations, e.g., the ADL-Registry, ASPECT, GLOBE, LORN, LRE, MELT. Each of these federations has established its own rules for participation and its own model of a resource federation. While these community federations provide an effective means to discover educational resources, all of the capabilities that a user may require or desire (e.g., publishing, harvesting, accessing, delivering, annotating, classifying, tagging, ranking, browsing, syndicating) may not be supported, or most likely will be supported in different ways in different federations... One approach to address part of this mismatch is for the federations, the tools, and the underlying repositories to use interoperability standards. However, there are competing standards, thus adding to the complexity, and many interoperability standards address only technical issues, e.g., defining particular data models and representations... They do not specify how the representation is used to provide a useful behavior, e.g., the data model is expressed only as an XML schema, and cannot be used without using that technology...
A complementary approach is to describe the behaviors of the federation in terms of independent 'services', where a service provides an interface that exposes a behavior to clients, but hides details behind the interface; invoking the service results in a response or a change in the state of that which the service manages... In a service-oriented approach, these business capabilities are mapped to business processes, each of which choreographs a workflow of services. The identified services can be used in designing a federation, or can be reused in other systems. The FRED model enumerates these services, provides a particular composition of these services, and, as described, can be used as a prototype for modeling other resource federations, placing resource federations within the larger landscape of service-oriented educational computing systems.
Using the formal service-oriented modeling and documentation approach of the e-Framework provides a way to separate the overall resource federation model from the model of the individual services; a way to split the general description of a service from its many possible forms that use different interface and messaging technologies; and a way to identify the role and use of interoperability standards both within the behavior and representation descriptions of a service and across multiple service interactions..."
Preservation Planning: From TIFF to JPEG 2000?
Hannes Kulovits, Anna Kugler (et al.), D-Lib Magazine
"Studies and user reports claim JPEG 2000 to be (or at least will become) the next archiving format for digital images. The format offers new possibilities, such as streaming, and reduces storage consumption through lossless and lossy compression...
Another often claimed advantage of JPEG 2000 is that the master image can possibly serve as the access copy as well, and thus replace derived compressed, low resolution access copies. The National Library of the Netherlands (KB-NL) evaluated the suitability of alternative file formats such as JPEG 2000 to their currently used format uncompressed TIFF. The four aspects, required storage capacity, image quality, long-term sustainability and functionality were analysed and JPEG 2000 is recommended as future archive format. The British Library recently moved forward to migrate their 80-terabyte newspaper collection from TIFF to JPEG 2000, and the Wellcome Library announced they will use JPEG 2000 for their upcoming digitization projects...
In this article, we describe the work we've done in the Bavarian State Library (BSB), and the sample objects we've chosen, as well as discuss the requirements, considered alternatives, experiment settings, and results of our work... During the semi-automated production process, the bibliographic, technical, administrative and structural information of each volume is stored with our electronic publishing framework ZEND (Zentrale Erfassungs- und Nachweisdatenbank), which is based on Open-Source Software, in a separate XML file based on TEI P5, which we use for the correct access of the images (physical and logical structure of the images are mostly not congruent). The technical metadata of the images are always stored representatively for the whole volume on the 11th page of each volume..."
See also: Wikipedia on JPEG 2000
SCA Components with Spring: Advanced Techniques Using Apache Tuscany
Ramkumar Ramalingam, IBM developerWorks
Apache Tuscany "simplifies the task of developing SOA solutions by providing a comprehensive infrastructure for SOA development and management that is based on Service Component Architecture (SCA) standard." This article "explores some of the advanced features supported by the Apache Tuscany runtime. It demonstrates how multiple application contexts can be combined and used to implement your SCA component. An example walks you through SCA annotations used to explicitly declare the SCA services, references, and properties within your Spring bean classes...
The SCA runtime creates the target application context instance for a multiple application context scenario. You also learned how SCA annotations can be used to explicitly declare the SCA services, references, and properties within your Spring bean classes.
Together, SCA and Spring make a powerful combination. Spring provides the infrastructure to develop your components with increased productivity and runtime performance, while improving test coverage and application quality. SCA provides the necessary infrastructure to assemble and model your components based on a Service-Oriented Architecture. SCA lets your components expose services, wire service components together, and deal with heterogeneous distributed systems..."
See also: Apache Tuscany
3D Media and the Semantic Web
Michela Spagnuolo and Bianca Falcidieno, IEEE Intelligent Systems
"3D content is widely recognized as the next wave of digital media. The success of 3D communities and mapping applications (for example, Second Life and GoogleEarth) and the decreasing costs of producing 3D environments are leading analysts to predict a dramatic shift in how people see and navigate the Internet...
The Digital Shape Workbench (DSW), developed in the Advanced and Innovative Models And Tools for the Development of Semantic-Based systems for Handling, Acquiring, and Processing Knowledge Embedded in Multidimensional Digital Objects (AIM@SHAPE) Network of Excellence project, represents a unique infrastructure prototype for storing scientific resources and supporting research activities. The infrastructure is knowledge based to take into account taxonomies of geometric representations and ontologies describing work-flows of 3D modeling and processing operations, while also implementing various search mechanisms. The AIM@SHAPE model repository stores more than 700 high-quality models, each characterized by a large set of metadata spanning from simple Dublin Core to more specific geometryoriented metadata, structured according to the Common Shape Ontology. The ontology is expressed in OWL...
Current standards for expressing geometric data, such as X3D, allow the possibility of describing compound scenes as assemblies of simpler ones and describing behaviors and interactions, but this is mainly considered a standard to code information needed for interactive applications rather than for a 3D Semantic Web. Traditional geometric representations, in various types, could be enhanced with tags, annotations, and even hyperlinks to other 3D models, making them evolve toward what Havemann and Fellner call generalized 3D documents... Each instance is related to one part of the model, and it's defined by its URI, its type (the class the feature belongs to) and other attribute values and relations. In its current version, the ShapeAnnotator saves the geometric representation, augmented with information about the segmentation, into a single file, and saves the instances as a separate OWL file that imports the domain ontology. This is a partial solution. The problem of defining a stable 3D markup remains.
In the current panorama of 3D search engines, there's no satisfactory way to search for a semantically relevant feature (e.g., a house or a tree) in a 3D scene or 3D models repository, unless the 3D models have been manually annotated with keywords, which reduces the problem to a text search. Researchers are exploring contentbased search to overcome this problem by letting users search for 3D content resembling a sketched query or by using a query-by-example..."
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.||http://sun.com|
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/