This issue of XML Daily Newslink is sponsored by:
Web Services for Remote Portlets Specification (WSRP) Version 2.0
Rich Thompson (ed), OASIS Public Review Draft
Members of the OASIS Web Services for Remote Portlets Technical Committee have released a third Public Review Draft of "Web Services for Remote Portlets Specification v2.0." The public review period ends 22-September-2007. The OASIS WSRP TC aims to simplify the effort required of integrating applications to quickly exploit new web services as they become available. The Web Services for Remote Portlets (WSRP) specification defines a web service interface for accessing and interacting with interactive presentation-oriented web services. It is based on the requirements gathered and on the concrete proposals made to the WSRP technical committee. Scenarios that motivate WSRP functionality include: (1) Content hosts, such as portal servers, providing Portlets as presentation-oriented web services that can be used by aggregation engines. (2) Aggregating frameworks, including portal servers, consuming presentation-oriented web services offered by content providers and integrating them into the framework. The WSRP standard layers on top of the existing web services stack, utilizing existing web services standards and will leverage emerging web service standards (such as policy) as they become available. The interfaces defined by this specification use the Web Services Description Language (WSDL). Integration of remote content and application logic into an End-User presentation has been a task requiring significant custom programming effort. Typically, vendors of aggregating applications, such as a portal, write special adapters for applications and content providers to accommodate the variety of different interfaces and protocols those providers use. The goal of this v2.0 specification is to enable an application designer or administrator to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks and no programming effort.
See also: the announcement
The 'application/docbook+xml' Media Type
Norman Walsh (ed), IETF Internet Draft
IETF announced that a new Best Current Practice (BCP) specification is available from the on-line Internet Drafts directories: "The 'application/docbook+xml' Media Type" defines the 'application/docbook+xml' MIME media type for DocBook-based markup languages. From the draft: "The DocBook specification has for many years included an appendix which defines a MIME media type for DocBook. This [Internet Draft] document makes that media type official. By virtue of DocBook XML content being XML, it has the same considerations when sent as 'application/docbook+xml' as does XML. There is no experimental, vendor specific, or personal tree predecessor to 'application/docbook+xml', reflecting the fact that no applications currently recognize it. This new type is being registered in order to allow for the deployment of DocBook on the World Wide Web, as a first class XML application. For documents labeled as 'application/docbook+xml', the fragment identifier notation is exactly that for 'application/xml', as specified in 'XML Media Types' (RFC 3023) or its successors. Security Considerations: An XML Resource Identifier does not in itself pose a security threat. However, XML Resource Identifers are often converted to IRIs or URIs and subsequently used to provide a compact set of instructions for access to network resources, care must be taken to properly interpret the data within an XML Resource Identifier, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text." Application Media Types are registered with IANA (Internet Assigned Numbers Authority, formally The Internet Corporation for Assigned Names and Numbers). Registration of media types based on XML is described in the IETF Request for Comments #3023. Note: DocBook V5.0CR5 was released 12-July-2007. It is the fifth Candidate Release of DocBook V5.0, being a RELAX NG reimplementation of DocBook. It is a significant redesign that attempts to remain true to the spirit of DocBook. "There are no user-visible changes in DocBook V5.0CR5; if no bug reports are received before the August, 2007 DocBook TC meeting, this version will become the offiical DocBook V5.0 release."
See also: the DocBook 5.0 Definitive Guide
Compound Document Formats: W3C Call for Implementations
Timur Mehrvarz, Lasse Pajunen (et al., eds), W3C Technical Reports
W3C announced that The Compound Document Formats Working Group has released four Candidate Recommendations: "Compound Document by Reference Framework 1.0", "WICD Core 1.0", "WICD Full 1.0", and "WICD Mobile 1.0." WICD ('Web Integration Compound Document', pronounced "wicked") addresses by-reference composition and processing of "compound documents", which are documents that combines multiple formats. Implementor feedback is invited through 1-December-2007. A preliminary implementation report is available, and a test suite is under development. "Combining content delivery formats can often be desirable in order to provide a seamless experience for the user. For example, XHTML-formatted content can be augmented by SVG objects, to create a more dynamic, interactive and self adjusting presentation. A set of standard rules is required in order to provide this capability across a range of user agents and devices. Compound Document by Reference Framework (CDRF) that defines a language-independent processing model for combining arbitrary document formats. CDRF is "language-independent": while it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., CSS, MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats. The "WICD Core" specification describes rules for combining Extensible Hypertext Markup Language (XHTML), Cascading Style Sheets (CSS), and Scalable Child Content formats, such as Scalable Vector Graphics (SVG), in a device independent manner. WICD Core 1.0 is based upon the Compound Document by Reference Framework 1.0 (CDRF) and serves as a foundation for the creation of rich multimedia content profiles. "WICD Full 1.0" is targeted at desktop agents and is a superset of "WICD Mobile 1.0." The Compound Document Format Working Group will advance the CDRF 1.0 to Proposed Recommendation no sooner than 01 September 2007; the Working Group estimates that by 01 December 2007 the following exit criteria have been met: (1) there are at least two implementations of CDRF user agents; (2) the dependent documents must have reached CR status (3) at least one profile conforms to the Framework.
See also: WICD Core 1.0
WADL: The REST Answer to WSDL
Daniel Rubio, TechTarget
Web service developers were stirred a few months ago in the technical media over the SOAP vs. REST debate, a now familiar theme which seems to come up every so often and one discussion which will surely never be completely settled given that each approach has its own technical merits on which to stand. But appropriate as each technique is for certain circumstances, until recently, there was one obvious part missing in RESTful approaches that was ever present in SOAP: the concept of a descriptor. Web Application Description Language (WADL) aims to provide descriptors for RESTful services. For SOAP Web services, descriptors based on Web Services Description Language (WSDL) form a fundamental piece of their actual design, mainly on account of the underlying complexity present in the actual service. In these scenarios, a descriptor not only serves the purpose of formally describing all the business logic it can fulfill, but it also aides in the creation of helper classes (often called stubs) used to build service clients. While the mechanics of using [WADL's] approach (automated code generation) have caused criticism among early WADL analysts, stating that it's not only unnecessary, but that it will start REST down the same path as SOAP and other distributed technologies like CORBA, which depend on intermediate languages/descriptors, from a practical point of view one cannot deny that using such a contract to obtain stub classes is an even quicker way to get started with REST-based Web services clients. While WADL is still in its early phases and tools are currently available only for Java environments—contrary to WSDL, which is more ubiquitous—WADL's appearance is a vote of confidence in favor of the REST approach to building Web services and will in all likelihood become a tight knit companion when undertaking REST designs in the enterprise, just like WSDL has been one for SOAP.
See also: the WADL Project web site
New Version of the W3C Markup Validation Service
Olivier Thereaux, W3C Announcement
Olivier Thereaux (W3C Coordinator of Open Source development of QA Tools) announced that the W3C Markup Validator v0.8.0 was released, formally named the "W3C Markup Validation Service". The application is available as a free service online or as a free download. The online validator checks the markup validity of Web documents in HTML, XHTML, SMIL, MathML (etc) using document URI, file upload, or direct forms-based input. "Version 0.8.0 is a major milestone in the development of the validator, including changes in its architecture, UI, new features and fewer bugs, for a better, more accurate and helpful quality process. Changes include: (1) New architecture, faster and more reliable, scaling better to the growing usage of the validator; (2) Improved interface for better usability, accessibility; (3) New feature: automatic cleanup of markup with Tidy; (4) New feature: additional XML-Well-Formedness check, for more reliable validation of XML-based languages; (5) New feature: checking that the documents are sent with proper Internet Media Type [MIME type]; (6) New feature: for XML documents, checking that the 'xmlns' is present, and properly set; (7) New feature: grouped messages, an alternate view to the sequential display of errors; (8) New feature: Direct Input form can be pre-filled with basic document structure; in other words, it is now possible to check 'chunks' of HTML, for inclusion in templates or CMS code; (9) New feature: For non-xhtml XML documents without document type, the validator will not try to perform validation and will only check well-formedness; (10) Added support for SMIL 2.1, XHTML Basic 1.1, XHTML + RDFa. The markup Validator is one of the many open source software projects created and maintained at W3C: your participation in sending feedback and ideas, patches and bug reports helps build better tools..."
See also: the announcement
Whose Data Is It, Anyways?
Patrick Durepos, Canadian Underwriter
For a long time, industry observers have pointed out that many property and casualty insurance companies use a 'silo' method of storing disparate data and information. It's a valid observation, but what about brokers? Every day, insurance intermediaries collect, store and send a myriad of client information. Yet when it comes time to access that data and use it to meet their unique business needs, brokers encounter far more obstacles than opportunities. Many technology vendors seem to be moving in the opposite direction when it comes to openness of data and access to information. Instead of extending functionality and creating standard interfaces, some technology vendors are encrypting data and creating even greater barriers for brokers to access their own information. One type of interface can be provided so that all integrations are done using the same fundamental mechanisms. Using the XML format of the Centre for Study of Insurance Operations (CSIO) standard, this process has become much easier and more feasible. For example, Keal Technology has shown that, through its partner Brovada and the nexisys solution, brokers can exchange data seamlessly with insurance companies through the industry XML standard. The next step, using API, is to open the door even wider, through standardized XML messages. We want to extend functionality beyond just sending policy information back and forth to insurance companies. The API allows brokers to access their information and manipulate it as they see fit without negatively impacting the product... Open architecture, integration standards based on CSIO XML, enhanced reporting capabilities and more seamless methods of data capture, storage and access. These are the traits today's insurance intermediaries should be demanding from their technology providers. [Note: CSIO web site declares that the XML standards "files are available to CSIO members only."]
See also: the CSIO CEPA newsletter
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/