This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- Service Modeling Language Version 1.1: New Working Drafts
- Mapping Documents in the Binary Format to the Open XML Format
- Proposed IETF Working Group for vCard and vCardDAV
- Eclipse Swordfish SOA Runtime Mixes SCA, JBI, and OSGi
- IPFIX Implementation Guidelines
- W3C Invites Implementations of SMIL 3.0 Candidate Recommendation
- U.S. National Weather Service Starts Multi-Phase CAP Improvement Project
- Last Call Review for IETF NETCONF Event Notifications
- Update: Yahoo to Support OpenID Single Sign-On
Service Modeling Language Version 1.1: New Working Drafts
Bhalchandra Pandit, Valentina Popescu, Virginia Smith; W3C Technical Report
W3C announced that members of the Service Modeling Language (SML) Working Group have published the third Working Drafts for "Service Modeling Language, Version 1.1" and "Service Modeling Language Interchange Format Version 1.1." The former specifies SML 1.1, used to model complex services and systems, including their structure, constraints, policies, and best practices. SML uses XML Schema and is based on a profile of Schematron. The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex services and systems. Depending on the application domain, these models may include information such as configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. The companion SML Interchange Format (SML-IF) specification defines markup to identify the model being interchanged, to distinguish between model definition documents and model instance documents, and to bind rule documents with other documents in the interchange set. An SML model is a collection of XML documents that may be used to describe complex services and systems such as a set of IT resources, services and their interrelations. In every SML model there are two distinguished subsets of the model's documents, the definition documents and the instance documents. The model's definition documents describe the abstract structure of the model, and provide much of the information a model validator needs to decide whether the model as a whole is valid. The model's instance documents describe or support the description of the individual resources the model portrays. The SML Specification identifies two categories of model definition documents that participate in model validation: Schema documents and rule documents. To ensure accurate and convenient interchange of the documents that make up an SML model or a portion of an SML model, it is useful to define an implementation-neutral interchange format (SML-IF) that preserves the content and interrelationships among the documents. Details on the Member Submission of Service Modeling Language (SML) Specification to W3C are provided in an earlier news story.
See also: the W3C SML Working Group web site
Mapping Documents in the Binary Format to the Open XML Format
Brian Jones, Open XML Formats Blog
"A few interesting developments in Ecma's proposed disposition document related to the Office binary formats: (1) There were a few comments from national bodies that asked about the documentation of the Office binary formats and the availability of those documents. We had already been talking about these issues in TC45 where there were a number of existing experts in the binary formats (including Apple, Novell, and Microsoft). Based on the feedback from the national bodies, Microsoft decided last week to take some additional steps in this area. The first issue National Bodies were interested in was easier availability of the documentation of the binary formats (.doc; .xls; .ppt). It sounded like the main concern here was around the extra steps required to get the binary documentation. The current form of the documentation has been available since 2006.. The new proposal we (Microsoft) made to Ecma TC45 was that we'd just get rid of the need to send an e-mail and we'd provide it for direct download under the OSP. (2) The second issue we had feedback on was an interest in the mapping from the binary formats into the Open XML formats. The thought here was that the most effective way to help people with this was to create an open source translation project to allow binary documents (.doc; .xls; .ppt) to be translated into Open XML. So we proposed the creation of a new open source project that would map a document written using the legacy binary formats to the Open XML formats... We will modify DIS 29500 to include an informative reference to the SourceForge project.
See also: Mary Jo Foley's blog
Proposed IETF Working Group for vCard and vCardDAV
IESG Secretary, Working Group Review Announcement
A new Working Group for "vCard and vCardDAV (vcarddav)" has been proposed for the IETF Application Area. The IESG has not made any determination as yet, but requests public comment by January 22, 2008. Description: " A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC 2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies -- for example, a per-entry UUID or per-attribute sequence number. (2) An address book access protocol leveraging the vCard data format; the Internet-draft 'draft-daboo-carddav' will be the starting point. Among the secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML-centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted.
See also: XML in the the IETF Applications Area
Eclipse Swordfish SOA Runtime Mixes SCA, JBI, and OSGi
Rich Seeley, SearchSOA.com
The swordfish (xiphias gladius) uses its sharp elongated bill to slash through its prey making sushi of smaller fish. Likewise, the advocates of a service-oriented architecture (SOA) platform codenamed Swordfish, which is now making its way through the Eclipse incubator process, argue it will slash through obstacles to SOA development. Those obstacles include political infighting between advocates of the Java Business Integration (JBI) and Service Component Architecture (SCA) specifications as well as features missing in the Java Enterprise Edition (JEE), said Ricco Deutscher, CTO at SOPERA GmbH, a spinoff of Deutsche Post AG. The parent company developed its own SOA platform to handle logistics applications. Deutscher is now leading the open sourcing of the Open Service Gateway initiative (OSGi)-based SOA platform in Eclipse. In the third quarter of this year, Swordfish is scheduled to emerge from incubation as the SOA runtime integrated with Eclipse SOA Tools Project (STP) and the Web Tools Project (WTP), Deutscher said. Swordfish will also make the best use of both JBI and SCA, ending that rivalry, and employ OSGi to replace Java EE and even Spring. In Deutscher's view of Swordfish, SCA provides a common programming model and a common description format. JBI provides a common messaging model. OSGi provides a common deployment model and a common runtime component model. [From the Swordfish web site:] "The goal of the Swordfish project is to provide an extensible service-oriented architecture (SOA) framework that can be complemented by additional open source or commercial components such as a service registry, a messaging system, a BPEL engine etc. to form a comprehensive open source SOA runtime environment based on both established and emerging open standards. The framework shall be usable for a wide range of applications—from embedded systems to enterprise environments."
See also: the Swordfish web site
IPFIX Implementation Guidelines
Elisa Boschi, Lutz Mark (et al., eds), IETF Internet Draft
The IESG has approved the "IPFIX Implementation Guidelines" specification as an Informational RFC. The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. The IPFIX Protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX exporting process to a collecting process is defined in the IPFIX Architecture document, per the requirements defined in RFC 3917. The IPFIX Architecture also specifies how IPFIX data record and templates are carried via a congestion-aware transport protocol from IPFIX exporting processes to IPFIX collecting process. IPFIX has a formal description of IPFIX information elements, their name, type and additional semantic information, as specified in the IPFIX Information Model. The Information Model document contains an XML-based specification of Template, abstract data types and IPFIX Information Elements, which may be used to create consistent machine-readable extensions to the IPFIX information model. This description can be used for automatically checking syntactic correctness of the specification of IPFIX Information Elements and for generating code that deals with processing IPFIX Information Elements. In this document, we provide guidelines for its implementation. The guidelines are split into five main sets. These sets address implementation aspects for Template management, Exporting Process, Collecting Process, transport, and implementation on middleboxes. Note: The IESG Secretary recently announced the re-charter of the IETF IP Flow Information Export (IPFIX) Working Group in the Operations and Management Area. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the IEF NETCONF Working Group.
W3C Invites Implementations of SMIL 3.0 Candidate Recommendation
Dick Bulterman, Jack Jansen (et al., eds); W3C Technical Report
W3C's SYMM Working Group has published the Candidate Recommendation of Synchronized Multimedia Integration Language (SMIL 3.0), an XML-based language that allows authors to create interactive multimedia presentations. A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience. SMIL 3.0 design goals are to: (1) Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL, an author can describe the temporal behaviour of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen. (2) Allow reusing of SMIL syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL components are used for integrating timing into XHTML and into SVG. (3) Extend the functionalities contained in the SMIL 2.1 into new or revised SMIL 3.0 modules. (4) Define new SMIL 3.0 Profiles incorporating features useful within the industry. The SYMM Working Group is building a test suite help ensure interoperable implementation. The SMIL 3.0 test suite will provide at least one test case for any new element or new attribute or new attribute value introduced in SMIL 3.0 and sufficient tests also for any SMIL 2.1 functionality that might be impacted by new features of SMIL 3.0.
See also: the W3C Synchronized Multimedia Activity
U.S. National Weather Service Starts Multi-Phase CAP Improvement Project
Herb White, National Weather Service (NWS) Aware Report
This article was published in the 2008/Volume 1 NOAA NWS Aware Report by Herb White, NWS Dissemination Services Manager. [An earlier article] "described the proposed addition of Instruction Field 'markers' into NWS WMO-formatted text Watch/Warning/Advisory/Statements (W/W/A/S). The proposal is not intended to make W/W/A/S products into Common Alerting Protocol (CAP) formatted messages or even move in that direction. Rather, it is needed to improve NWS production of the separate suite of CAP messages by early 2009 to include distinct event 'Description' and 'Instruction' elements. Without a marker, there is no reliable way to parse the CAP Instruction element from existing WMO-formatted text products and create a separate CAP Instruction element. This proposal is the only change to existing NWS products enabling CAP message production. NWS has an experimental Webpage that provides reformatted W/W/A/S products in Extensible Markup Language (XML) for various feeds and displays. These CAP messages have not been satisfactorily formatted. World Meteorological Organization (WMO) formatted products do not provide information needed to populate certain CAP fields. To aggressively respond to the urgent need for standardized CAP compliant message format for NWS W/W/A events, NWS has started a multi-phased project with some tasks progressing in parallel. NWS will request public review and comment on proposed improvements shortly. NWS will improve the experimental CAP-formatted messages and continue to make them available online. At the same time, NWS will develop the Next Generation Warning Tool (NGWT) that will generate CAP messages in native format. NGWT will deliver AWIPS W/W/A applications through a more standardized approach than currently used. NGWT will modularize the applications. This will allow warning applications to be flexible enough to respond to changing technologies and user requirements. Products issued using the new NGWT will be formatted for transmission on NOAAPort, the NWWS, and NWS Webpage... This CAP solution will provide numerous benefits [including]: (1) Partners will have XML/Keyhole Markup Language formats to enable use of NWS products in better ways, such as with Geographic Information System applications. In addition XML reduces the cost of entry for NWS partners to parse and use NWS local products; for example, rip currents alerts will be available in standard national formats. (2) CAP will enhance government's "situational awareness" at the state, regional and national levels by providing a continual real time database of all warnings, even local ones. Local warnings in CAP, unavailable to state and local officials at present, could be crucial to the timely evaluation of certain threats, like biological terrorist attacks, which are most readily identified by detecting patterns in local responses... A future Aware article will describe how NWS CAP initiatives relate to other CAP initiatives in and outside the federal government.
See also: the OASIS CAP standard
Last Call Review for IETF NETCONF Event Notifications
Sharon Chisholm and Hector Trevino (eds), IETF Internet Draft
The Internet Engineering Steering Group has received a request from the Network Configuration Working Group (NETCONF) to consider the "NETCONF Event Notifications" specification as an IETF Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action through 2008-01-29. This memo defines a mechanism whereby the NETCONF client indicates interest in receiving event notifications from a NETCONF server by creating a subscription to receive event notifications. The NETCONF server replies to indicate whether the subscription request was successful and, if it was successful, begins sending the event notifications to the NETCONF client as the events occur within the system. These event notifications will continue to be sent until either the NETCONF session is terminated or the subscription terminates for some other reason. The event notification subscription allows a number of options to enable the NETCONF client to specify which events are of interest. These are specified when the subscription is created. The motivation for this work is to enable the sending of asynchronous messages that are consistent with the data model (content) and security model used within a NETCONF implementation. The contents of all event streams made available to a NETCONF client (i.e., the notification sent by the NETCONF server) MUST be encoded in XML. Section 4 presents the XML Schema for Event Notifications. An "event" is something that happens which may be of interest—a configuration change, a fault, a change in status, crossing a threshold, or an external input to the system, for example. Often this results in an asynchronous message, sometimes referred to as a notification or event notification, being sent to interested parties to notify them that this event has occurred. A "subscription" is an agreement and method to receive event notifications over a NETCONF session. A concept related to the delivery of notifications (if there are any to send) involving destination and selection of notifications; it is bound to the lifetime of a session.
Update: Yahoo to Support OpenID Single Sign-On
Juan Carlos Perez, InfoWorld
Yahoo announced that people with a Yahoo user name and password will be able to use that ID information to access non-Yahoo Web sites that support the OpenID 2.0 digital identity framework, reducing the amount of different log-in information people need to create, remember and enter online. Already, almost 10,000 Web sites support OpenID, an open framework available for free to end users and Web site operators alike, according to the OpenID Foundation. Yahoo's move will triple the number of OpenID accounts to 368 million by adding its 248 million active registered users to the rolls, the company said Thursday. OpenID addresses one of several issues related to giving people more control of their online activities. Other groups are focusing on data portability, to let people move around the data and content they create online, so that they don't have to enter it manually in, say, every social-networking site they sign up for. Other major players that have expressed interest and gotten involved in varying degrees with OpenID include Google, Six Apart, AOL, Sun, Novell, and Microsoft... Yahoo participated in the development of version 2.0 of the OpenID framework, which the company said provides new security features. Yahoo users who log in to third-party OpenID sites should know that the log-in process doesn't reveal e-mail or instant-message addresses.
See also: the announcement
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.com|
|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: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/