This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- New Working Draft for XProc: An XML Pipeline Language
- Proposed Recommendations for W3C Web Services Policy 1.5
- GCN Insider: DITA to That
- IBM Zeroes In On Project Zero for Web 2.0 Applications
- Netconf XML Schema Query
- REST vs. WS-*: War is Over (If You Want It)
- The Atom Publishing Protocol
- Threats to GEOPRIV Location Objects
- Microsoft Rejects Latest Open Source License
New Working Draft for XProc: An XML Pipeline Language
Norman Walsh and Alex Milowski (eds), W3C Technical Report
W3C Staff announced the publication of a new Working Draft for the XML Pipeline specification, produced by members of the W3C XML Processing Model Working Group. "XProc: An XML Pipeline Language" describes the syntax and semantics of a language for describing operations to be performed on XML documents. An XML Pipeline specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output. A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their input and produce zero or more XML documents as their output. The inputs to a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded. There are two kinds of steps: atomic steps and compound steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned, whereas compound steps include a subpipeline of steps within themselves. The XProc specification defines a standard library of steps in Appendix A (Standard Step Library). Pipeline implementations may support additional types of steps as well. Norm Walsh reports in the associated Blog: "... think our latest draft, published today, is getting pretty close. This draft resolves (finally, I hope) the question of how to deal with parameters. I don't think we've quite dotted the I's and crossed the T's on how the new parameter story interfaces with the outside world, but I'm confident that we'll get there. We've also introduced a new defaulting story; I expect this will generate feedback, both positive and negative... I hope the next draft is our Last Call draft and I hope it comes out in July ..."
See also: Norm Walsh's blog
Proposed Recommendations for W3C Web Services Policy 1.5
Asir Vedamuthu, Dave Orchard, Frederick Hirsch (et al, eds), W3C PRs
See also: Web Services Policy Working Group
GCN Insider: DITA to That
Joab Jackson, Government Computer News
Service-oriented architecture aims to turn computational processes into services so they can be used for missions beyond their original scope. Now, an emerging Extensible Markup Language (XML) product promises to do the same for text. Developed by IBM and later released to OASIS as an open standard, the Darwin Information Typing Architecture, or DITA, is an XML Document Type Definition that can be used to mark up different sections of documents so they can easily be found later and reused in other documents. Although IBM first came up with DITA for its technical documents, it could be used across a wide range of organizational material, said Ann Rockley, who leads the Rockley Group consulting firm. Rockley spoke at the recent Gilbane content management conference in Washington. Perhaps the most surprising thing about Rockley's presentation is how easy DITA is for end users. Most good DITA-aware editors look like a version of Word loaded with organizational style sheets, she said. Each document has different sections, specifying title, author, and the different topics and subtopics. Each topic or subtopic can be specified by the user or an organizational list of topics compiled in a component management system; these topics are indexed for later retrieval. Reuse can happen in a number of different ways. Frequently reused snatches of text, such as boilerplates, definitions or policy statements, can easily be called up and placed into documents. Another good use is for what Rockley called multichannel documents, where one basic piece of text has to be used in multiple forms, such as in a brochure, on a Web page or for a white paper.
See also: the DITA.XML.org community resource
IBM Zeroes In On Project Zero for Web 2.0 Applications
Paul Krill, InfoWorld
See also: the Web site
Netconf XML Schema Query
Mark Scott (ed), IETF Internet Draft
IESG has announced the publication of an Internet Draft for "Netconf XML Schema Query" in the IETF Standards Track. The NETCONF protocol (Request for Comments 4741, December 2006) defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets. The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange. The "Netconf XML Schema Query" document defines a mechanism to retrieve a list of XML Schemas supported by a NETCONF server. This is an optional capability built on top of the base NETCONF definition. The document defines the capabilities and operations necessary to support this service.
See also: the NETCONF Configuration Protocol
REST vs. WS-*: War is Over (If You Want It)
David Chappell, Blog
To anybody who's paying attention and who's not a hopeless partisan, the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side—it's Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward. If you doubt this, take a look at Microsoft's forthcoming support for creating RESTful applications in the next release of Windows Communication Foundation (WCF). The official Java world is also on board, with the impending creation of JAX-RS. Since both worlds also have good support for the WS-* approach, developers will be able to choose the approach that's best for a particular application. Two big questions remain. The first is, What exactly is REST? By far the best and clearest definition I've seen is provided by RESTful Web Services, a wonderful book by Leonard Richardson and Sam Ruby. If everybody can buy into the measures of RESTfulness this book provides, we can all avoid lots of future arguments. As a side benefit, it will let most of us get by without reading Roy Fielding's PhD thesis, the canonical text on REST. The second question is, When should each approach be used? Whatever partisans may claim, neither technology is right for every situation. While hammering out a true understanding of this will likely take some time, the basic outlines are clear. A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios. Lots and lots of apps fit this model, especially on the public Internet. A solution based on WS-* makes more sense for service/method-oriented applications, especially those that need more advanced behaviors such as transactions and more-than-basic security.
The Atom Publishing Protocol
Joe Gregorio and Bill de hOra (eds), IETF Internet Draft
The IETF has issued a revised (-16) Internet Draft for "The Atom Publishing Protocol" specification, now progressing through in the IESG Processing/Evaluation stage. The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations, where the Atom format is documented in the "Atom Syndication Format" specification (IETF Request for Comments #4287). APP uses HTTP (RFC 2616) and XML 1.0. The protocol supports the creation of Web Resources and provides facilities for: (1) Collections: Sets of Resources, which can be retrieved in whole or in part; (2) Services: Discovery and description of Collections; (3) Editing: Creating, editing, and deleting Resources. APP uses Atom-formatted representations to describe the state and metadata of those Resources. It defines how Collections of Resources can be organized, and specifies formats to support their discovery, grouping and categorization. APP uses HTTP methods to author Member Resources as follows: GET is used to retrieve a representation of a known Resource. POST is used to create a new, dynamically-named, Resource. When the client submits non-Atom-Entry representations to a Collection for creation, two Resources are always created—a Media Entry for the requested Resource, and a Media Link Entry for metadata about the Resource that will appear in the Collection. PUT is used to edit a known Resource. It is not used for Resource creation. DELETE is used to remove a known Resource. Changes in -v16 include minting a new NS URI at the W3C domain: 'http://www.w3.org/2007/app'.
See also: the diff
Threats to GEOPRIV Location Objects
Richard Barnes, Matt Lepinski (et al., eds), IETF Internet Draft
Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have published an initial Internet Draft specification "Threats to GEOPRIV Location Objects." The memo relates to location information as defined in RFC 4119: A Presence-based GEOPRIV Location Object Format (Request for Comments 4119) describes an object format for carrying geographical information on the Internet. The location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. RFC 4119 defines the PIDF-LO location object format, which extends the Presence Information Document Format to carry location information and rules regarding transmission and processing of that location information. A PIDF-LO document contains four essential types of information: Identifiers for the described presentity, location information, time-stamps, and rules. By grouping values of these various types together within an XML structure, a PIDF-LO document encodes a set of bindings among them. Presence-based location objects used by Internet protocols encode bindings of location information to identities of a presentity, with associated rules for the handling and usage of the location object. Parties that make use of location objects rely on the accuracy of these bindings to ensure their proper function, and the entities that they describe rely on the proper application of the included rules to ensure their privacy. The I-D "Threats to GEOPRIV Location Objects" describes the space of attacks against location objects. The threat model focuses on how location objects can be misused or corrupted across its entire life-cycle—a more general type of threat than is addressed in RFC 3694, which focuses on a single hop in a putative store-and-forward system.
See also: the GEOPRIV Working Group Charter
Microsoft Rejects Latest Open Source License
Keith Ward, Application Development Trends
The Microsoft-Novell Linux alliance may have gotten shakier, with Microsoft saying it doesn't recognize the latest version of the standard license for open source software (OSS). In an recent announcement on its Web site, Microsoft stated, in blunt fashion, that it rejects the third iteration of the General Public License (GPLv3) governing OSS. The statement begins: "Microsoft is not a party to the GPLv3 license and none of its actions are to be misinterpreted as accepting status as a contracting party of GPLv3 or assuming any legal obligations under such license." GPLv3 has generated controversy for its stipulation that recent deals Microsoft has struck with a number of Linux developers and distributors like Linspire, Novell and Xandros will be illegal in the future. Despite the statement, Microsoft claimed that its stance will not affect its relationship with Novell, which was its partner in the first patent-infringement protection deal. Under the terms of that agreement, Microsoft said it would not hold Novell or any users of its Linux products liable for what Microsoft claimed in May are 235 OSS violations of its patents.
See also: GPLv3
Selected from the Cover Pages, by Robin Cover
OASIS has published six (6) Proposed Charter documents for new Technical Committees to be created within the Open Composite Services Architecture (Open CSA) Member Section. Formation of new Technical Committees was anticipated in the announcement of March 21, 2007, where eighteen technology vendors reported that key Service Component Architecture (SCA) and Service Data Objects (SDO) specifications had completed incubation, and would be formally submitted to OASIS for advancement through its open standards process. Some sixty-three (63) names are given as proposers (or supporters) in the six TC Proposed Charters, representing thirty-two (32) different individuals. Eleven (11) company names are associated with the proposers, including BEA, Cape Clear, IBM, Interface21, Oracle, Progress, Quovadx, Rogue Wave, SAP, Siemens, Sun, and TIBCO. The TC Charters as proposed identify some fifteen OASIS specifications that build upon the existing OSOA Service Component Architecture Version 1.0 Specifications, as described in earlier announcements. The draft charters submitted to establish the OASIS TCs are subject to review, and published comments are available online. The deadlines for review comments are 13-July-2007 (for SCA-Assembly TC, SCA-Policy TC) and 16-July-2007 (for SCA-Bindings TC, SCA-J TC, SCA-BPEL TC, and SCA-C TC).
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: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/