November 2002

• [November 30, 2002] "Cornering the Office." By P.J. Connolly. In InfoWorld (November 29, 2002). ['Office 11 beta's collaboration and XML features almost justify the upgrade.'] "... We actually found that although Office 11 Beta 1 contains the usual assortment of prerelease bugs, one or two of the new features do justify an upgrade for a small number of users. Among the enhancements to collaboration features, users of Word-created forms will find it easier to restrict access to selected portions of those documents. For the XML-obsessed, the Office 11 applications will provide easier ways to convert Office file formats into XML and vice versa (see 'Modeling biz docs in XML'). The new release of Office will prod sales of Windows XP, because Office 11 won't run on legacy Win9x/Millenium platforms, or even on Windows NT. It's Windows 2000 or Windows XP, or no upgrade for you. Not that this is entirely a bad thing, given our disdain for the 9x family and its obsolete, security-heedless architecture. But this underscores Microsoft's overwhelming dominance of the desktop and its ability to pressure customers into paying for endless upgrades by one means or another... The improvements to individual applications, although valuable, don't really justify the designation of a major upgrade. For example, Excel, PowerPoint, and Word now support ink markup using a Windows-based tablet PC. Access and PowerPoint 11 now support SmartTags. PowerPoint's 'Package to CD' feature is a noticeable improvement over earlier attempts, and one can finally access Word's thesaurus from inside PowerPoint 11. And as we noted, Word now offers more control over document entry, making it a better form-filler than ever. But the enhanced XML support in the Office 11 Beta applications qualifies the suite as a major upgrade. Word 11 supports XML as a native file format, while Access 11 and Excel 11 are better consumers of XML data sources; all three offer improved support for user-defined XML... Although we don't expect consumers and end-users to rush to Office 11, due primarily to the requirements, Beta 1 shows us that enterprises using XML to transform their business process will reap the most benefit from its improved support for user-defined schemas and better import and export facilities. Some of the collaboration improvements, including selective document protection, can make a difference now. But the impact of others such as STS [SharePoint Team Services] must wait to be seen..." See: "Microsoft Office 11 and XDocs."

• [November 30, 2002] "Building Rules into Web Services Applications." By Henry Bowers (ILOG Inc). In Web Services Journal Volume 02, Issue 12 (December 2002), pages 7-8. "This article discusses several ways in which applications can be intelligently partitioned to make the best use of business rules... Companies that haven't carefully segregated rules from other business logic are confronted with two choices: divide the application as best they can, or simply slap a Web services front end on the monolithic application. ... the latter approach is the most common. It doesn't require a lot of effort at a programming level. Such implementations generally place software such as a principal mortgage application module on an intranet as a Web service. Other applications send the module large SOAP-wrapped XML records containing all relevant applicant data for approval. When the software approves the application, it returns to the client the necessary text to drop into loan document templates. This solution is quick, inexpensive, and effective; however, it does not make optimal use of business-logic components. The second approach is to separate business rules from the business logic. Depending on the construction of the applications, this can be fairly easy... other applications can now make use of the same rules... Web services provide a unique opportunity to implement this kind of reusability by carving out sets of rules into callable services. In addition, they encourage the conversion of many standalone data formats into XML, which has the benefit of simplifying overall application integration. Sites that choose this path are often surprised at how quickly benefits become apparent. The separation of rules processing as Web services can be implemented progressively. Complete conversions of applications are unnecessary. Also, once rules are segregated as Web services, new opportunities for their use appear quickly. For example, business analysts can much more easily perform what-if scenarios by rolling hypothetical data through the rules. A common implementation detail of this approach is the migration of rules from a code-based implementation to a business rule engine (BRE), an integral component of a business rule management system. A BRE applies business rules to application data, generally in a highly optimized fashion. However, its real importance is that it enables firms to specify rules in business terms rather than in code. This step permits sites to move rules formulation and testing outside of IT and into the hands of business analysts. These analysts now can formulate rules using their own vernacular, test the results, and go live when they're ready. Meanwhile, programmers are freed from the conversion of business policies into code and so can focus on other portions of the application. By using Web services and a BRE this scenario becomes possible. The rest of the application then interacts with the rule sets, which are now flexible and highly amenable to use in one-off situations. Because of this benefit, BREs are increasingly viewed as a central best practice for the implementation of policy-intensive applications... The rule-vending service is implemented as a Web service with a BRE and an interface to a business-rules repository... The rule-vending service has the ability to return an XML-based file containing the applicable business rules, a link to a Web service that applies a specific set of business rules, or the results produced by executing the business rules on the spot..." See also "Rule Markup Language (RuleML)." [alt URL]

• [November 30, 2002] "Building Interactive Web Services With WSIA and WSRP. One Step Toward Making Web Services What They Were Meant to Be." By Eilon Reshef. In Web Services Journal Volume 02, Issue 12 (December 2002), pages 10-16. December Feature Article. ['WSIA and WSRP are new Web services standards that enable businesses to create user- facing, visual, and interactive Web services that organizations can easily plug-and-play into their applications and portals. This article will familiarize you with these technologies and illustrate how they can help your businesses.'] "One of the main promises of Web services is enabling the assembly of Web applications from functional components distributed across multiple locations. However, until now the assembly of visual, rich, interactive Web applications with a cohesive flow and look-and-feel has been a challenge. Custom programming is required to create a user interface tier for each new Web service, resulting in set-up and maintenance efforts that render business initiatives cost prohibitive as the number of components increases. Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP) are standards for user-facing, presentation-oriented, interactive Web services intended to simplify the creation of distributed interactive applications. With WSIA and WSRP, Web services include presentation and multipage, multi-step user interaction. This lets service users plug them into sites and portals without custom development and leverage new functionality available in future versions of the service without the need for additional custom development WSIA and WSRP define a set of APIs that allow developers to produce and consume remote interactive Web services. They define three types of actors: (1) Producer: Represents the service provider hosting the remote interactive Web service -- for example, weather.com as a weather service provider; (2) Consumer: Represents the entity integrating the remote service into its Web application, oftentimes using a portal toolkit -- for example, Yahoo Weather or a corporate portal; (3) End User: Represents the person that comes to the Consumer Web site to use the Producer's application in the Consumer's context. In a nutshell, WSIA and WSRP fulfill the following roles: [1] Define the notion of valid markup fragments based on the existing markup languages, such as HTML, XHTML, VoiceXML, cHTML, etc.; [2] Provide a set of standard calls to enable a Consumer to request these markup fragments from a Producer based on the existing state; [3] Supply a set of calls that support the concept of multistep user interaction and preservation of state across those calls. There are four central parts to the WSIA and WSRP APIs: Retrieving markup fragments, encapsulated in the getMarkup() call; Managing state; Handling user interaction, encapsulated in the performInteraction() call; Supporting customization and configuration... WSIA and WSRP are important technologies that help bring the promise of Web services to end users by providing a standard to manage user interaction and application display. They enable business partners to integrate each other's online applications seamlessly, offering a more compelling experience to their customers. These technologies are complex under the hood and can only thrive if vendors deliver on the promise of building tools to manage the complexity. Given the breadth of the specification, it is not expected that companies will develop WSIA and WSRP solutions in-house. It is likely that they will instead rely on tools from vendors, keeping their focus on creating the application functionality. See: OASIS Web Services for Interactive Applications TC website; (2) OASIS Web Services for Remote Portals (WSRP) TC website; (3) WSRP-WSIA TC subcommittee mailing list. [alt URL]

• [November 30, 2002] "Modeling Biz Docs in XML." By Jon Udell. In InfoWorld (November 29, 2002). ['Unlocking Office 11's XML features means coming to grips with its data definition language, XML Schema. That won't be easy, but the sooner we start, the better. The future of Web services depends on our ability to model business documents in XML. Yes, XML Schema is complex, but some of the issues are more general. Even experts disagree on the best practices for object-oriented data modeling. Office 11 creates an environment in which we can start to codify those best practices as they apply to ordinary business documents.'] "The good news is that Office 11 supports XML Schema. The bad news is that XML Schema has been described even by XML experts as 'confusing,' 'impenetrable,' 'fuzzy,' and 'as user-friendly as a stick in the eye.' A successor to the SGML/XML DTD (Standard Generalized Markup Language/XML document type definition), XML Schema is a language for writing rules that constrain the kinds of elements that can appear in documents and the ways in which they can be sequenced, grouped, and nested. XML Schema is still a relatively new specification. The W3C Recommendation for XML Schema was published in May 2001. XML parsers that support XML Schema haven't done so for very long, and there is not yet much experience using it. Most people who are adept at defining document structure learned how to do so by writing DTDs. Some of the allergic reaction to XML Schema can, therefore, be chalked up to normal reluctance to learn new skills... Upgrading the word processors and spreadsheets on those government computers to versions that not only can read and write XML, but, more crucially, can enforce rules about datatypes and structures, is part of the solution. Assuming, of course, that such rules can be written, deployed, and unobtrusively applied and maintained over time. 'Therein,' observes Windley, 'lies the rub.' There is very little extant knowledge about how to model unstructured and semistructured data in XML. Unlike SGML, the XML DTD was always optional, because the framers of XML knew there was enormous value in documents that were merely well-formed, even if not valid with respect to a DTD. RSS (Rich Site Summary), for example, the wildly popular XML format for content syndication, has no DTD or schema... One possibility is to infer schemas from example documents. Tools can do this, but so far, not with much sophistication. Microsoft, for example, offers a .Net namespace (Microsoft.XsdInference) that will infer a schema from an XML document, and even refine that schema based on further examples. The results make a useful starting point, and inferencing is a promising technology that can and should evolve, but the fact is that modeling XML data is a complex subject that even the best human experts have yet to codify. XML Schema delivers a much richer set of modeling tools than were available to DTD authors. Learning to use them well is going to be a challenge..." General references in "XML Schemas"; see also "Microsoft Office 11 and XDocs."

• [November 27, 2002] "A New Way of Collaborating." By David M. Ewalt. In Information Week (November 25, 2002). ['Standards are being developed with which companies will create business processes.'] "Standards bodies and software vendors are putting the final touches on a number of Web-services specifications that could revolutionize the way companies collaborate. The standards are related to XML, a language used by businesses to model enterprise data that's become an instrumental part of Web services. While the technology that underlies each of the new specs marks up data similarly to XML, its capabilities go far beyond that of XML's. 'This is something weird and different,' says Howard Smith, chief technology officer at Computer Sciences Corp. Europe. 'It's not Web services, it's not the reinvention of workflow, it's not process-management workflow, it's new. It unifies those things. It's like taking the best of every other paradigm and building a nice new model.' BPML, the Business Process Markup Language, is published by the Business Process Management Initiative, a group backed by dozens of major IT vendors, including BEA Systems, CSC, SAP, and Sun Microsystems. It released the first draft of the language in August. Compared with XML, BPML lets users model a company's business processes from top to bottom. Using BPML, a company can define every action in a complex business process--anything from sending a price bid to executing a purchase and shipping goods. If every company used the language to define their processes, the processes would become interchangeable. Two companies that want to team on an order, a project, or a transaction could interact at the process level, not so much trading data as working together to perform different parts of common procedures. Tools based on BPML will do to processes what spreadsheets did to data: let companies treat their processes like easily definable objects that can be changed or linked to other processes with a simple point and click... A consortium of businesses, including BEA, IBM, and Microsoft, has a competing standard, BPEL, or Business Process Execution Language, under construction. The first draft of the BPEL4WS (as in 'for Web services') spec was born in August, when IBM and Microsoft brought together two existing technologies (IBM's WSFL, or Web Services Flow Language, and Microsoft's XLANG) to create the new standard. Paraic Sweeney, IBM's VP for business integration, describes the function of the new specification as similar in scope to technologies like Open Database Connectivity and Java... ODBC and Java Database Connectivity provide a standardized way of talking to a database, independent from the developer that produces it, Sweeney says, and the same thing has occurred in application development and application servers with Java 2 Enterprise Edition... BPEL and BPML are similar in scope, yet having two standards would probably compromise the goal of getting everyone speaking the same language. Sweeney says he's confident the two standards will merge at some point. Others, like CSC's Smith, figure BPML will win... Along with Microsoft, Siebel is pushing BPEL as the key standard for that revolution; versions of the Universal Application Network due next year will support the spec, among other standards. 'This is basically the next generation of computing languages,' Siebel says. 'It's a very exciting idea.' CSC is implementing the new languages into software incrementally, Smith says. Later this year, its e3 architecture will be updated to include a full-featured business-process management engine capable of interpreting BPML..."

• [November 27, 2002] "Ipedo Upgrades Native XML-Based Suite." By Lisa Vaas. In eWEEK (November 27, 2002). "Ipedo Inc. next week will ship Dynamic Information Suite 3.2, an update of a native XML-based suite that features virtual document links, full-text XQuery searches, XML indexing and flexible content organization to simplify access to distributed content. The upgrade, originally announced in September, provides a platform for integrating, organizing and managing change for mixed content in portals, custom Web applications and Web services. Virtual Documents is a feature that allows users to define documents consisting of references to any content, in other documents or in other systems, through XML views. The feature allows content to be linked from any point in an XML document. Links can be modified over time as new or updated content comes online, without affecting the actual content or its storage. Full-text XQuery search enables searches that return only those components of a document that match the query, rather than the entire document. Self-managing XML indexes simplify the creation and management of indexes on content. They are automatically managed and optimized based on use and query patterns on individual XML documents and document collections... Pricing is on a per-CPU basis and starts at $75,000..."

• [November 27, 2002] "Explore the Web Services Bus, Part 1. Using a UDDI-Based Discovery Mechanism to Make Publishing and Discovering Web Services a Breeze." By Greg Flurry (Senior Technical Staff Member, IBM Software Group). From IBM developerWorks, Web services. November 2002. ['If you've downloaded version 3.2.2 of the Web Services Toolkit from IBM alphaWorks, you already have the Web Services Bus, a framework for constructing Web services processors. In this two-part series, Greg Flurry shows you how to get started using the Bus to get your Web services into production faster and more easily. In this first installment, you'll learn about the Bus's UDDI-based discovery mechanism, and examine an experimental practice that will help automate the process of publishing Web services.'] "The Web Services Bus, available in version 3.2.2 of the Web Services Toolkit at IBM alphaWorks, is a framework for constructing Web services processors. With the Bus, you can create Web service clients, servers, gateways, intermediaries, and more. The Bus goes beyond other Web services frameworks to offer an enhanced environment for conducting dynamic e-business with Web services. It supports service requestors with a client-side on-ramp and supports service providers with a server-side off-ramp. The Bus, through its Web Services Invocation Framework (WSIF) heritage, has WSDL at its core; Web services deployed in the bus off-ramp (called bus services) can be described with WSDL, and the off-ramp can dynamically generate WSDL for bus services. Further, the Bus off-ramp optionally publishes information about bus services in UDDI registries. In addition, the Bus supports formalized, pluggable discovery and selection mechanisms in the Bus on-ramp. Briefly, the Bus accepts requests for a particular implementation of a WSDL portType, but invokes the discovery and selection mechanisms to direct the requests to different implementations. The pluggable discovery and selection mechanisms can use any means desired to find candidate implementations and subsequently select one desired implementation from among the candidates... [You will] learn about a number of aspects of the Web Services Bus related to WSDL, UDDI, and Bus discovery. In particular, how to create a UDDI registry-based discovery mechanism, and how to leverage an experimental practice implemented by the Bus to do efficient searches in a UDDI registry for services implementing a particular portType. A more sophisticated discovery mechanism could examine other UDDI registries, WSIL registries, databases, or other sources of candidate implementations for the portType. Similarly, though the sample code selects a service at random, a more sophisticated selection mechanism could make an intelligent choice, perhaps based on cost or service level agreement terms, if such information were available. One final thought: Though the discovery implementation in this example ran in the client on-ramp, similar techniques can be used in the Bus's server on-ramp. This would allow the Bus server side to be configured to do interesting things as an intermediary, similar to the Web Services Gateway, also available on alphaWorks... In a future article, I'll examine bus filters, another feature of the Web Services Bus that enhances the Bus's abilities as a framework for Web services..." General references in (1) "Web Services Description Language (WSDL)"; (2) "Universal Description, Discovery, and Integration (UDDI)."

• [November 27, 2002] "IBM developerWorks Web Services Demos." By [IBM Staff]. From IBM developerWorks, Web services. November 2002. ['Since its first release in 2000, the IBM Web Services Toolkit has become one of the most popular downloads from the IBM alphaWorks site and one of the leading Web services implementations. The Toolkit has led the way in demonstrating emerging technologies, allowing people an unprecedented glimpse into the future of Web services. Due to its popularity, we have decided to include some of the demos and their matching documentation through our Web Services Demo Collection, allowing you to try out the Toolkit before downloading and installing it on your system.'] "The Web Services Toolkit (WSTK) for dynamic e-business is a software development kit that includes demos and examples to help in designing and executing Web service applications that can automatically find one another and collaborate in business transactions without additional programming or human intervention. Simple examples of Web services are provided, as well as demonstrations of how some of the emerging technology standards, such as SOAP, UDDI, and WSDL, work together. The WSTK is based on top of the stable development platform and runtime environment of the IBM WebSphere SDK for Web Services (WSDK) also available from developerWorks. The WSTK showcases emerging technology in Web services and is a good way to get an understanding of the most recently announced Web services specifications. However, for a product-level development environment for Web services, IBM WebSphere Studio Application Developer is recommended. It allows creation, building, testing, publishing, and discovering of Web service-based applications that support UDDI, SOAP, WSDL, and XML. An overview of the WSTK objectives and relationship to IBM products is available in an article about WSTK on the IBM dynamic e-business site. A description of the new features added to WSTK is located in the FAQ document on alphaWorks... There are several Web Services Toolkit demos to choose from. Each demo provides a link to overview information and directions for running the demo..." See details in: (1) the related article "IBM Web Services ToolKit: A Showcase For Emerging Web Services Technologies," by John Feller (Senior Development Manager, IBM Emerging Technologies Development); (2) Updated IBM Web Services Tool Kit (WSTK) Version 3.3.

• [November 27, 2002] "XML Content Standard Could Challenge Microsoft." From [Analytical Source] Rita Knox. Gartner FirstTake Report. Reference: FT-18-9097. 25 November 2002. ['The Organization for the Advancement of Structured Information Standards (OASIS) seeks to advance open XML-based file specifications for office applications. If OASIS succeeds, Microsoft will face greater competition.'] "Although the outcome of the OASIS initiative may be interesting and useful, it will be incomplete, because Microsoft is not a participant. Microsoft has a virtual monopoly in the office application market. The OASIS committee's aim is to establish standards for data interoperability among applications such as word processing, spreadsheets, charts and graphs, while retaining high-level information for editing. If it achieves this aim, content (regardless of form) will be created in any application, opened from within any other application and edited as needed. The eventual goal is to enable interchange among any type of application, including databases, search engines and Web services. Vendors are backing the initiative because they have a vested interest in loosening Microsoft's stranglehold on the market -- particularly in the face of Microsoft's XML-based Office 11, which is scheduled to be launched in mid-2003. Microsoft's absence also may be due to OASIS's intellectual property policy for participation (royalty-free, and reasonable and nondiscriminatory licensing), which may make Microsoft reluctant to participate when it is about to release its XML-aware product suite. The involvement of Boeing is significant because it provides user endorsement and strong user input to the committee's work. Gartner will closely monitor progress on this standard's activity..." See references in: (1) "OASIS Technical Committee for Open Office XML File Format"; (2) "XML File Formats for Office Documents." [Also in HTML format]

• [November 27, 2002] "Web Services We'd Like To See." By Timothy Appnel. From O'Reilly Network Weblogs. November 26, 2002. "In a recent CNET article ['Amazon, Google Lead New Path to Web Services'], Margaret Kane reports on Google and Amazon's success with Web services and the benefits they are beginning to reap. Tim O'Reilly provides his commentary on the piece [in 'Why Amazon and Google Web Services Matter']. O'Reilly notes a key takeaway from Amazon and Google's success is "...the importance of a decentralized approach rather than a top-down approach by a single vendor." In addition to his comments, I think it's also interesting to note that two service providers are driving real Web service adoption and not software vendors such as Microsoft and IBM. (Could this be an indication of a significant shift in the industry?) Being a developer I want to see more service providers support general use Web services. I've been pondering this for a while, but the recent CNET article and the attention it has received put my thinking into high gear. Here are some of the service providers that I would like to see follow Google and Amazon's lead: [eBay, PayPal, FedEx, UPS, MapQuest, Yahoo, Any site with information and news lacking RSS support...]

• [November 26, 2002] "Message Queuing for Business Integration." By Dieter Gawlick (Oracle, Server Technology Division). In EAI Journal Volume 4, Number 10 (October 2002), pages 30-33. ['Given the title, you may think this article was first published a few years ago. But, in fact, it looks at database-driven MQ -- specifically, the reasons that companies may choose to move their communication data out of file-based message queuing systems and into database-enabled message queuing systems.'] "In response to increasingly demanding communication requirements, message queuing technology has become a central part of today's computing infrastructure. While most communication is still based on e-mail technology, the increased demand for structured communication with high service quality levels has led more companies to embrace and extend the use of message queuing technology. Message queuing technology has rapidly evolved to meet the challenges of companies integrating their businesses... Probably the best-known and most widely used example of a filebased message queuing system is IBM's WebSphere MQ (formerly MQSeries). In database-oriented message queuing systems, one or more queues are mapped to tables and messages are mapped to database records, normally called rows. This approach to message queuing is much more recent. Either the file- or database-oriented approach can handle the basic message queuing requirements. Both methods provide support for a message format and methods for sending and receiving messages... With file-based message queuing, creation and consumption of messages transactionally consistent with database updates require: (1) Support for distributed two-phase commit coordination; (2) Journaling; (3) Journal management; (4) Recovery. The cost of distributed two-phase commit processing for the synchronization with the companion database can diminish performance and scalability. While the technology is well-understood, the actual implementation proves to be extremely difficult and expensive. Only leading file-based message queuing systems provide transactional support for message queuing. In contrast, transaction support is inherent in the database. With a databaseenabled messaging system, messages can be transactionally stored in queues mapped to database tables. These operations can be committed or rolled back as part of a transaction that includes other standard database operations. By collocating the operational data with the queues, the need for distributed, two-phase commit is eliminated... Autonomous applications perform tasks that need to be coordinated with tasks performed by other applications within the same or in different companies. Message queuing, one of the core technologies for this task, has to provide the communication in a highly reliable, scalable, secure manner while providing auditing and tracking. Similar requirements are found in other environments such as business-to-consumer (B2C) and peer-to-peer. For many of the same reasons that companies have chosen to move their operational data out of files and into a database -- reliability, security, scalability, performance -- they now can choose to move their communication data out of file-based message queuing systems and into database-enabled message queuing systems..."

• [November 26, 2002] "Group Calls For New Disaster Warnings." By Robert Lemos. In CNET News.com (November 26, 2002). "The diffuse emergency warning systems in the United States need a revamp, which should include a mandated messaging standard, a panel of emergency-response experts concluded in a report... The panel -- formed of experts in disaster response from the government, the academic and the private sectors -- maintained that the current hodgepodge of warning systems, including the Emergency Alert System and the NOAA Weather Radio, don't work well. 'While many federal agencies are responsible for warnings, there is no single federal agency that has clear responsibility to see that a national, all-hazard, public warning system is developed and utilized effectively,' stated the Partnership for Public Warning in the report, which called for the newly formed Department for Homeland Security to take charge... The new system must be able to communicate with a variety of devices, including computers, cell phones, pagers and any new electronic gizmo, stated the report. For that reason, the report highlights XML (Extensible Markup Language), as a likely candidate, but other protocols might be desirable for noncomputing platforms. In addition, the report says messages must be able to have a unique identifier, a way to specify geographic regions for different levels of warning, and encryption methods for validating the sender of the message. The panel also called for additional research into the efficacy of such warnings, into the extent of trust that can be placed in the public as a source of information about disasters, and into the effect of a great number of false warnings on the public. Currently, a variety of alerts can be sent out using several different systems. The National Weather Service warns of dangerous weather patterns and incidents in specific areas of the country, while the U.S. Geological Survey alerts affected parts of the country of earthquakes, volcanic eruptions and landslides. The Department of Justice issues notice of criminal activities, and the Environmental Protection Agency sends out warnings concerning air and water quality..." General references in "XML and Emergency Management."

• [November 26, 2002] "Adobe FrameMaker 7.0." By Robert J. Boeri. In EContent Magazine (November 2002). EContent Decision-Maker Review. "FrameMaker's support of XML, a Web-capable subset of SGML, is new in version 7.0. The World Wide Web Consortium (W3C), developers of XML, released the original XML standard in February 1998. This review emphasizes FrameMaker's XML capabilities rather than the older (and less used) SGML standard... FrameMaker 7.0 comes bundled with Quadralay's WebWorks standard edition, a tool for producing HTML (optionally styled with cascading stylesheets), outputs to MS Reader and Palm Reader, and XML styled either with cascading stylesheets or XSL, the family of W3C XML formatting and transformation standards. FrameMaker's major new features are: Full support for XML 'round tripping,' assuring valid XML both into and from FrameMaker. Support for three sample XML applications: DocBook 4.1, xDocbook 4.1.2, and one of the three XHTML DTDs; CSS Export, which allows automatic generation of CSS style definitions for XML files; expanded support for SVG graphics -- another Adobe strength -- as either raster or pass-through graphics in their original XML renditions; ability to generate Acrobat 5 'tagged PDF.' This can enhance document accessibility by allowing flexible reflows of text on a broad range of reader devices; support for Unicode, 8- and 16-bit UTF characters. This can eliminate the need to buy special Asian-language printing devices; and extensive support for non-English fonts, for example: double-byte for Japanese, simplified and traditional Chinese, Korean, as well as many European and Scandinavian languages. There are no XML analysis and design tools bundled with FrameMaker. To design XML stylesheets or DTDs, you must purchase separate XML suites such as Altova's XML Spy or Tibco's Turbo XML. There is also no FrameMaker integration with those tools. Adobe provides the best solution for long and richly structured technical documents, and Adobe has an undisputed track record for supporting detailed layouts and multilingual fonts. The closest competitors are hybrid XML Word offerings (such as BroadVision's One-to-One Content) and native XML publishing offerings such as Arbortext's Epic and Corel SoftQuad's XMetaL. Because native XML publishing systems immediately recognize DTDs (or schemas), mapping files are not necessary with them..." See also the review in "XML Powers Document Builders."

• [November 26, 2002] "Seeds of SVG Being Planted: Will they Grow?" By Luke Cavanagh. In The Bulletin: Seybold News and Views On Electronic Publishing Volume 8, Number 9 (November 27, 2002). "E-periodicals are a growing blip on the publishing radar screen these days, though their ultimate success is still a point of contention. Some believe Microsoft's efforts to make the Tablet PC a reading platform could spur sustainable interest; others think the future will remain cloudy until significant all-around improvements are made. Still, vendors search for a formula that would make e-publications -- magazines, newspapers, newsletters, journals, etc. -- a primary reading choice for the mass market rather than a digitized supplement to print editions... Two companies, Mattercast and Texterity, recently introduced early-stage software based on Scalable Vector Graphics (SVG) that can easily reproduce print layouts in online editions without the need to use the Adobe Acrobat Reader. The vendors tout faster download speeds, optimization of graphics for the Web and the ability to customize the look and feel of the content's packaging as advantages of using SVG instead of plain PDF. Although it is important to realize that the efforts of both Texterity and Mattercast are in their early stages, each thus far provides little compelling evidence that supports the use of SVG in such applications... The Web would really benefit from increased use of vector graphics, and we see great potential for publishers of all types to embrace SVG in their online publications. For the right type of material, vector graphics load faster, look better, and are much easier to make interactive than their raster counterparts. Unfortunately, drawing e-renditions of printed pages is not the right application for SVG..." On Texterity's SVG support in TextCafe, see: (1) the announcement "TextCafe Version 3.0 Now Supports SVG. Generates Scalable Vector Graphics, Enhanced Navigation XML, Document Indexes."; (2) the online presentation "TextCafe 3.0 Release Overview Scalable Vector Graphics (SVG)." General references in "W3C Scalable Vector Graphics (SVG)."

• [November 26, 2002] "Perspective: The Five Biggest Myths About Web Services." By Bob Sutor (IBM). In CNET News.com (November 26, 2002). "Two-and-a-half years into the evolution of Web services, and the hype surrounding this technology has become deafening. The good news is that after you strip away the bravado, there is still a lot to be excited about. Web services is starting to pay early dividends for some companies, but the big payoff is still two or three years down the road. By then, Web services will be the standard for doing business with customers, suppliers, and partners. Right now, the trick is separating reality from fantasy. With that in mind, here are five big myths and facts about Web services that can help guide you from illusion to truth... Web services is the distillation of knowledge and experience gained from decades of working with distributed technologies. Essentially, Web-services technologies allow businesses to share the information they have stored in their computer applications with other applications in the company or with those run by customers, suppliers and partners. By connecting these processes online, companies can significantly increase the efficiency -- and thus lower the cost -- of running their enterprise... Web services exists because interoperability is not only possible; it's happening on IT systems every hour of every day. Interoperability is managed through middleware, software that allows applications to run and communicate on multiple operating systems. The adoption of open standards by more and more companies means that this middleware will allow IT systems to interact seamlessly, no matter what operating systems or applications are used... When we log on to the Internet for personal use, we don't think about whether our software will be compatible with whatever is on the other end of our web browsers. The important standards work at the World Wide Web Consortium (W3C) made this happen for the Internet. Why should this not be true for business applications as well? Companies and organizations around the world are cooperating on standards and programming languages, such as Java, that can enable all software, including older applications, to interoperate productively on the Web and to be upgraded or transitioned rather than 'ripped and replaced.' There are honest differences of opinion on how all of this should be accomplished, but overriding the differences is a spirit of cooperation driven by an industry desire to make Web services work. That's why the important Web services work in the Organization for the Advancement of Structured Information Standards (OASIS) and the W3C is proceeding so well..."

• [November 26, 2002] "XML Spy Tops as XML Editor." By Timothy Dyck. In eWEEK (November 25, 2002). "Altova GMBH's XML Spy has long been a strong player in the XML space, and Version 5 of the XML editor raises the bar even higher. Of all the XML editors eWEEK Labs has seen -- and we've seen a lot -- the $990 XML Spy 5.0 Enterprise Edition provides the best overall combination of editing power and usability, along with wide database and programming language integration support. This earns the product an eWEEK Labs Analyst's Choice award. XML Spy's user interface -- particularly its graphical schema editing tools and grid-based XML data editor -- keeps impressing us with its versatility, intuitiveness and power. For quick, ad hoc XML transformations, such as converting a series of attributes into elements, XML Spy is a perfect tool. The Enterprise Edition of XML Spy is new to the product line. It includes cutting-edge HTML-to-XML conversion capabilities; Java and C++ code generation; and Web services features, including a Simple Object Access Protocol debugger and a graphical WSDL (Web Services Description Language) file editor. The $399 Professional Edition of XML Spy does not have these features but does include the XML and XML Schema editing features, database import and export capabilities, and the XSLT (Extensible Stylesheet Language Transformations) debugger found in 5.0... The XSLT debugger in the new XML Spy line is important not only because it will be highly useful to developers, but also because it was one feature the competition had that XML Spy didn't. Excelon Corp.'s Stylus Studio 4.5, for example, has a very effective XSLT debugger... Also significant in XML Spy 5.0 is a new feature that helps automate the conversion of an HTML-based site to one that is based on XML technologies. XML Spy accomplishes this by transforming XML source data through Extensible Stylesheet Language into HTML... Plus: HTML-to-XML conversion capabilities; XSLT processor and debugger; graphical WSDL editor; Java and C++ code generators for XML data structures; Web services debugger; powerful XML editing features. Minus: Lacks support for DB2 and Sybase Adaptive Server Enterprise XML database extensions." For schema description and references, see "XML Schemas."

• [November 25, 2002] "XML Common Biometric Format (XCBF)." OASIS TC Working Draft, Version 01. Sunday, 17-November-2002. 81 pages. Edited by Phillip H. Griffin (Griffin Consulting). Produced by members of the OASIS XML Common Biometric Format (XCBF) TC. Contributors: Tyky Aichelen (IBM), Ed Day (Objective Systems), Dr. Paul Gérôme (AULM), Phillip H. Griffin (Chair, Griffin Consulting), John Larmouth (Larmouth T&PDS Ltd), Monica Martin (Drake Certivo), Bancroft Scott( OSS Nokalva), Paul Thorpe (OSS Nokalva), and Alessandro Triglia( OSS Nokalva). "Biometrics are measurable physical characteristics or personal behavioral traits that can be used to recognize the identity of an individual, or to verify a claimed identity. This specification defines a common set of secure XML encodings for the patron formats specified in CBEFF, the Common Biometric Exchange File Format (NISTIR 6529). These CBEFF formats currently include the binary biometric objects and information records in two ANSI standards. These XML encodings are based on the ASN.1 schema defined in ANS X9.84:2002 Biometrics Information Management and Security. They conform to the canonical variant of the XML Encoding Rules (XER) for ASN.1 defined in ITU-T Rec. X.693, and rely on the same security and processing requirements specified in X9.96 XML Cryptographic Message Syntax (XCMS). Values of the Biometric Information Record (BIR) defined in ANSI/INCITS 358-2002 - Information technology - BioAPI Specification can be represented in the X9.84 biometric object format can also be represented using XML markup and secured using the techniques in this standard. This standard defines cryptographic messages represented in XML markup for the secure collection, distribution, and processing, of biometric information. These messages provide the means of achieving data integrity, authentication of the origin, and privacy of biometric data in XML based systems and applications. Mechanisms and techniques are described for the secure transmission, storage, for integrity and privacy protection of biometric data." Sources: ZIP archives for the v01 spec and schemas. General references in "XML Common Biometric Format (XCBF)."

• [November 25, 2002] "Web Services Security XCBF Token Profile." Edited by Phillip H. Griffin (Griffin Consulting) and Monica J. Martin (Drake Certivo Inc). Submitted to the OASIS Web Services Security TC (WSS). OASIS TC Working Draft. Version 1.0. Monday, 25 November 2002. 15 pages. From the Introduction: "This document describes the use of XML Common Biometric Format (XCBF) cryptographic messages within the WS-Security specification. XCBF messages are validated against an ASN.1 schema. This schema definition language is used to define X.509 certificates and CRLs, and the cryptographic messages used to secure electronic mail in RFC3369 and X9.96 XML Cryptographic Message Syntax. In an instance of communication, XCBF messages may be represented in a compact binary format or as well-formed XML markup. A common XCBF security token is defined to convey and manage biometric information used for authentication and identification. Each binary representation of an XCBF message has an XML markup representation. Both representations share the same schema. This characteristic allows XML markup to be used in resource rich environments, but transferred or stored in a compressed binary format in resource poor environments, e.g., smart cards, wireless and remote devices, and high volume transaction systems. XCBF messages may include digitally signed or encrypted information. The binary format used to represent XCBF messages relies on the canonical Distinguished Encoding Rules (DER) used to encode X.509 certificates. The XML markup format used in this Standard is the canonical variant of the XML Encoding Rules (XER)." See also: (1) OASIS XML Common Biometric Format (XCBF) TC website; (2) "Web Services Security Specification (WS-Security)"; (3) general references in "XML Common Biometric Format (XCBF)."

• [November 25, 2002] "XMP: The Path to Metadata Salvation? [Content Management.]" By Bill Rosenblatt. In The Seybold Report Volume 2, Number 16 (November 25, 2002). ISSN: 1533-9211. ['Everyone admits that metadata is central to managing digital publishing workflows and distribution processes. XML and the related RDF gave us a common syntax for representing metadata, but they can't solve the whole problem, which includes communicating metadata between systems and standardizing the schemas. That's where Adobe's Extensible Metadata Platform comes in, allowing applications to capture metadata as digital assets are being created and allowing files to carry their own metadata wherever they go. What XMP can't provide is widespread user agreement on consistent sets of values for metadata elements.'] "Now that XMP [Extensible Metadata Platform] has celebrated its one-year anniversary, it's a good time to re-evaluate it... The current version of the XMP spec is 1.6, dated June 2002. Adobe has incorporated XMP support into the following applications: Acrobat 5, Illustrator 10, InDesign 2, InCopy 2, GoLive 6, LiveMotion 2, FrameMaker 7, Photoshop 7, Adobe Graphics Server (née AlterCast), and Adobe Document Server. For all of these applications, Adobe has built in a standard XMP dialog box that allows users to enter and edit the metadata for each file. In addition to the native file formats used by the above applications, Adobe has tools for embedding and extracting XMP packets in generic JPEG, GIF, EPS and TIFF file formats... Adobe needs to continue to walk the fine line between too little and too much detail in its metadata schemas. Right now, XMP is an exemplar of a lean, tightly conceived standard with very little excess baggage. Adobe will need to fend off the inevitable pressure to bloat XMP's out-of-the-box schemas with extra elements just to satisfy one constituency or another. At the same time, Adobe will need to ensure that XMP is maximally compatible with existing segment-level metadata standards, especially those like NewsML and ONIX that are not based on Dublin Core. Adobe could accomplish this by working with the groups in charge of those standards and developing mappings (aliases, in XMP parlance) to those other standards. Will XMP finally solve the metadata problem? Well, not entirely. At the heart of the metadata problem [...] is the need to create values of metadata. As mentioned before, some of these are easy to create automatically, while others involve manual labor. Many publishers find it hard to get people in the habit of creating metadata, and even when they do, they may not do it consistently; for example, they may define the same terms with different keywords. General solutions to this problem are unknown, yet tools like taxonomies, controlled vocabularies and categorization technologies can help minimize the problem. The latter have reached the point where they can really help automate metadata-creation processes and make metadata more consistent. As more and more publishing processes go digital, there's a greater understanding of the nature of metadata as the key to process efficiencies and product value-add; and along with that understanding have come a growing number of vendors who continue to chip away at the metadata problem. The problem will likely never be entirely solved, but with XMP, Adobe is poised to take the biggest chunk out of it since the invention of XML..." See: "Extensible Metadata Platform (XMP)."

• [November 25, 2002] "What is an RSS Channel, Anyway?" By Mark Nottingham. Reference posted to the RSS-DEV Mailing List. November 25, 2002. [A working document that provides an 'examination of the uses of RSS channels, to better understand their nature and to move towards a rigerous definition of them.'] "... The headline syndication view of RSS is straightforward; a channel is a reverse-chronological sorted list of links to stories, along with metadata for each one indicating the title and sometimes a description. This is the model that most developers and users of RSS have in mind to this day, and it is a useful one. However, a few people quickly noticed that it was easy to extend RSS to say other things about those links; in fact, you could say almost anything just by adding an element as a child of <item>. This metadata summary view of RSS ('Rich Site Summary' or 'RDF Site Summary') treated the channel as a container for any kind of statement - from market data to mp3 playlists to event calendars or even order systems - as long as what they were talking about could be arranged in a list. The modularity of RSS1.0 enables its use in a variety of contexts, from Wall Street to Open Source software distribution. Last but not least, Weblogs have been using RSS for something completely different - content syndication. Instead of just saying things about the channels' links, they reproduce the content at the other end, so that a Web resource can be replicated in whole in an aggregator or on another site. All of these views of RSS use the channel to group items together. None of them, however, establish what a channel actually is. In other words, although items are somewhat well-understood (having identifiers and metadata associated with them), the relationships between the items, in the context of a channel, hasn't been explored so much as it has been assumed..." [Note from the 2002-11-25 post: "The discussion on [RSS] 'items' is very timely; for some time I've been trying to figure out what a channel is, and have spent a little time recently writing it down. I'm not done yet, but the document captures the current state of my thinking and discussions I've had... Comments welcome..."] See "RDF Site Summary (RSS)."

• [November 25, 2002] "The Undecidability of the Schematron Conformance Problem." By Robert C. Lyons (Unidex, Inc). November 2002. "... The Post Correspondence Problem (PCP) is an undecidable problem... The proof that the PCP is undecidable can be built upon the undecidability of the Halting Problem. The undecidability of the PCP has often been used to prove the undecidability of other problems. It occurred to me that the undecidability of the PCP could be used to prove the undecidability of the Schematron Conformance Problem. In this paper, we'll describe the Schematron Conformance Problem (SCP) and Post Correspondence Problem (PCP). We'll then prove that the Schematron Conformance Problem is undecidable (even if we restrict ourselves to Schematron schemas that don't use the document and key functions). We assume that you are familiar with the basics of Schematron, which is a powerful XML schema language in which validity constraints are defined using XPath expressions... To prove that the SCP is undecidable, we show, by way of contradiction, that if the SCP is decidable, then the PCP is decidable..." Summary: "we showed that the Schematron Conformance Problem (SCP) is undecidable. This is true even if we restrict ourselves to Schematron schemas that do not use the document and key functions of XPath. To prove the undecidability of the SCP, we showed that if the SCP is decidable, then the Post Correspondence Problem is decidable; however, the Post Correspondence Problem is undecidable. Therefore, the SCP must be undecidable. The fact that the SCP is undecidable means that it's impossible to build a Schematron schema editor that evaluates the user's schema and always lets him/her know whether or not there are any XML documents that conform to the schema..." Note from Lyons in posting to XML-DEV: "Recently, I was reading about the Post Correspondence Problem (PCP), which is undecidable (i.e., unsolvable). I realized that the undecidability of the PCP could be used to prove that the following problem is undecidable: Given a Schematron schema, is there an XML document that conforms to this schema? If you're interested in reading the proof and a description of the PCP [see the paper]." See: "Schematron: XML Structure Validation Language Using Patterns in Trees."

• [November 25, 2002] "The Significance of CPPA v2." By Jon Bosak. Posting to 'ebXML-DEV' list 2002-11-23. "With the approval of ebXML CPPA v2 as an OASIS Standard this month, I think it would be useful to reflect for a moment on the significance of this milestone for ebXML and for electronic commerce in general. The standardization of OASIS ebXML CPPA v2 is of epochal importance for two reasons. First, the technology itself is central to the XML realization of the EDI trading model and, beyond that, to the implementation of large-scale B2B projects in general. It will be recalled that ebXML CPPA was originally developed by IBM as tpaML, the Trading Partner Agreement Markup Language. Some idea of the importance of IBM's contribution of tpaML to the ebXML initiative in early 2000 can be gained from an excellent IBM white paper on tpaML... a [related] presentation [from Martin W. Sachs] gives a good idea of the central role that tpaML was intended to play in IBM's plans for ecommerce and the similar role that CPPA will play in the ebXML ecommerce infrastructure.... The second reason that CPPA v2 will be of central importance for B2B has to do with the status of the intellectual property related to its implementation. ... [an IBM] patent [#6,148,290] covers features that might be essential to the implementation of a wide variety of ecommerce systems, not just ebXML. It's significant, therefore, that in May 2002, IBM promised to grant royalty-free licenses to all IBM patents required by CPPA v1 and v2 and committed to continue providing RF licenses for subsequent versions of CPPA. [See:] New IBM IP statement, IP statement from IBM, IBM OASIS ebXML Intellectual Property Disclosure, May 16, 2002. The royalty-free license was later extended to open-source software as well. Much has been made of the fact that CPPA v2 still cannot be considered completely unencumbered, but it remains, to my knowledge, the only application of the technology covered by the relevant IBM patents that IBM has publicly pledged to license royalty-free. The practical effect of this as far as I can see is to make ebXML the only TPA-based B2B ecommerce framework that can be implemented without incurring a future obligation to pay royalties to IBM for the TPA component..." See: (1) OASIS ebXML Collaboration Protocol Profile and Agreement TC website; (2) "Electronic Business XML Initiative (ebXML)."

• [November 25, 2002] "Web-Services Security Quality of Protection." Version 0.9. November 22, 2002. 25 pages. Text and reference posted 2002-11-22 to the OASIS 'wssqop-discuss' list by Tim Moses (Entrust) with the "Subject: QoP liaison statement". From the introductory 'Problem statement': "Using the WS Security Specification, service end-points have a standard means for securing SOAP messages using XML Signature and XML Encryption. However, the WSS specification does not provide a means for a Web-service consumer and provider to negotiate how the SOAP messages used in the exchange have to be protected in order to successfully invoke the service. In this paper, a technique for negotiating a mutually-acceptable security policy based on WSDL is proposed. The term security policy is used in this context to mean: 'a statement of the requirements for protecting arguments in a WS API', including: (1) how actors are to be authenticated, using what mechanisms and with what parameter value ranges, (2) which SOAP messages, elements and attachments are to be encrypted, for what individual recipients, recipient roles or keys, using what algorithms and key sizes, (3) which SOAP messages, elements and attachments are to be integrity protected, using what mechanisms, with which algorithms and key sizes and (4) what initial parameter values are used in the signature validation procedure, including what keys or authorities are trusted directly. This is a relatively restrictive use of the term 'security policy'. A more comprehensive definition addresses such requirements as: (1) privacy (retention period, intended usage, further disclosure), (2) authorization (additional qualifications the service consumer must demonstrate in order to successfully access the Web service) and (3) non-repudiation (requirements for notarization and time-stamping)... In some situations (notably RPC-style service invocation), Web service interactions are conducted in a persistent session. In such cases, the provider's security policy may indicate the requirements for authenticity, integrity and confidentiality of the session. In other situations (notably document-style service invocation), messages must be protected in isolation. In these cases, while the service provider may declare a policy, the service consumer actually creates the service request. So, the consumer actually chooses which security operations to apply to the messages. Therefore, we need a way for the consumer to discover the service provider's policy and choose a set of security operations that are consistent with both its own and the service-provider's security policies..." The note: "Colleagues: The WSS QoP Discussion Group has made significant progress since it was established as agreed at the first WSS Face-to-Face meeting. The results of its work can be found [online]... There is a significant body of opinion that the topic of QoP for Web-services is an important, and even urgent, one. The paper demonstrates that the problem is sufficiently well understood that a sub-committee of WSS could tackle it without impacting the schedule that has been established for the SOAP Message Protection specification. We therefore request that the WSS TC consider forming a sub-committee to address this work, and include an agenda item in its meeting of 3-December-2002 to discuss this request. [source]

• [November 25, 2002] "Tip: Control White Space in an XSLT Style Sheet. Create the Document You Want by Understanding White Space Stripping." By Nicholas Chase (President, Chase and Chase Inc). From IBM developerWorks, XML zone. November 2002. ['Because the style sheet and the source document in an XSLT transformation have different rules regarding white space stripping, it often seems as though the production of spaces and line breaks has no rhyme or reason in the process. This tip shows you how to control the production of white space in a transformation's result, which can lead to documents that more closely align with your requirements. For this tip, you can use any XSLT processor, such as Xalan or Saxon, or a browser-based solution, such as Microsoft Internet Explorer or Mozilla.'] "Before processing a transformation, an XSLT processor analyzes the style sheet and the source document, and removes any applicable white space nodes. It then processes the document, building the result tree from the remaining nodes... When the processor strips the white space nodes from an element, it first checks to see if that element is on a list of white-space preserving elements. By default, all of the source nodes are added to this list, but you can remove one (or more) by adding them to the xsl:strip-space element. For example, you can strip all of the white space nodes out of the question element in order to compress any responses within the question or answer texts... Adding white space to the style sheet: When the processor strips the white space nodes from the style sheet, only one element is, by default, on the list of white space preserving elements: xsl:text. A text element is always preserved, so it can be useful for adding line breaks or spaces within a document... By understanding the rules for white space preservation as they apply to a style sheet or a source document, you can closely control the appearance of the final document, but white space will never be stripped from within a text node..." See also the series "Controlling Whitespace, by Bob DuCharme. For related resources, see "Extensible Stylesheet Language (XSL/XSLT)."

• [November 25, 2002] "Coca-Cola, UCCnet Revamping Supply Chain." By Ted Kemp. In InternetWeek (November 25, 2002). "UCCnet, a product registry and subsidiary of the Uniform Code Council standards organization, said this month that Coke will begin implementing UCCnet's services in 2003. The beverage giant, which claims to have the world's largest distribution system, said it will use internal IT resources to integrate with retailers using UCCnet, first in North America and then globally. The announcement is a serious endorsement of UCCnet. The world's largest beverage company, Coca-Cola sells drinks in almost 200 countries at a rate of more than 1 billion servings a day. The agreement marks the latest in a string of endorsements for UCCnet. The Uniform Code Council and EAN International, its international counterpart, agreed in October to make UCCnet the central product data registry for international commerce. That followed endorsements from the Grocery Manufacturers of America and Food Marketing Institute, both major trade organizations. In August, UCC merged with RosettaNet, a developer of standards for e-business transactions... UCCnet currently stores information on only about 25,000 products, up from 15,000 in April. UCCnet's Monaghan said an upload from Procter & Gamble comprised a good portion of the growth. But he added that the 25,000 figure comes mostly from companies signed in the early part of this year and doesn't include the large number of companies signed since..." General references in: "Uniform Code Council (UCC) XML Program."

• [November 25, 2002] "Groove Ups .Net Support." By Dennis Callaghan. In eWEEK (November 25, 2002). "Groove Networks Inc. is expected to release version 2.5 of its Groove Workspace peer-to-peer collaboration software by the end of the year, offering improved support for .Net and Web services integration. This version will include a new .Net development tool, the Groove Toolkit for Visual Studio.net, which company officials say will make it easier and faster to build and deploy customer applications in Groove. Also featured in this release will be the Groove Web Services area, giving developers a new route to integrating Groove with other applications using SOAP. Customers will be able to build Groove-awareness into other applications -- so called contextual collaboration -- rather than building applications inside the Groove environment. Groove Workspace 2.5 will also feature improved integration with Microsoft Outlook, supporting Outlook calendars, meetings and contacts, and new integration with Microsoft SharePoint Team Services, which will allow Groove developers to synchronize SharePoint sites in a Groove space so that they can be used offline and extended outside the corporate firewall. Groove 2.5 will also support 'asymmetric files' --the ability to share files with other members of a shared space but to have control over whether these files are actually distributed immediately to all the other users. This allows users to pull down only the files they need to each machine. That feature is expected to be most useful for remote users sharing large document libraries, officials said..." See other details in "Extending Groove," by Jon Udell (InfoWorld).

• [November 22, 2002] "Microsoft, SAS, Hyperion Release New XMLA Specification." By Dennis Callaghan. In eWEEK (November 21, 2002). "... XML for Analysis (XMLA) is a Simple Object Access Protocol (SOAP)-based XML API, designed to standardize the data access interaction between a client application and a data provider via the Web. It requires no client software, unlike current data access techniques, such as OLE DB and ODBC, making it hardware, operating system and programming language independent. Version 1.1 of XMLA defines two new XML-based data access methods: Discover and Execute. Discover is used to obtain information and metadata from a Web service. This information can include a list of available data sources and data about the provider for a particular data source. Properties are used to define and shape what data is obtained. Discover allows users to specify the data obtained in a common way without rewriting existing functions. Execute is used to execute multidimensional expressions (MDX) or other provider-specific commands against a particular XML for Analysis data source. The Discover and Execute methods enable users to determine what can be queried on a particular server and, based on this, submit commands to be executed. The XML for Analysis provider then retrieves the requested data, packages it into XML and sends it back to the client. Members of the XMLA Council hope the specification, as it develops into a standard, will accelerate the adoption of Internet business intelligence software and increase the market for those technologies. The XMLA Council also announced seven new members today: Crystal Decisions, INEA Corp., MIS AG, MJM Consultant Corp., Panorama Software Systems, SAP AG and Silvon Software Inc., giving the council a total of 27 members..." See details in the 2002-11-21 news item "XMLA Advisory Council Announces XML for Analysis Specification Version 1.1."

• [November 22, 2002] "The Myths of 'Standard' Data Semantics. Faulty Assumptions Must Be Rooted Out." By William C. Burkett (Senior Information Engineer, PDIT). In XML Journal Volume 3, Issue 11 (November 2002). "Much of the literature heralding the benefits of XML has focused on its application as a medium for application interoperability. With (a) the Internet as a platform, (b) Web services as the functional building block components of an orchestrated application, and (c) XML as a common data format, applications will be able to communicate and collaborate seamlessly and transparently, without human intervention. All that's needed to make a reality is (d) for everyone to agree on and use XML tags the same way so that when an application sees a tag such as <firstName> it will know what it means. This intuitive understanding makes a lot of sense, which is why so many organizations have sprung into existence to create their own vocabularies (sets of tags) to serve as the 'lingua franca for data exchange in <insert your favorite industry, application, or domain>.' This intuitive understanding is so pervasive that it's even a key part of the U.S. GAO recommendations to Senator Joseph Leiberman (chairman of the Committee on Governmental Affairs, U.S. Senate) on the application of XML in the federal government. This report warns of the risk that: <q>...markup languages, data definitions, and data structures will proliferate. If organizations develop their systems using unique, nonstandard data definitions and structures, they will be unable to share their data externally without providing additional instructions to translate data structures from one organization and system to another, thus defeating one of XML's major benefits.</q>. The perspective of these efforts is that the standardization and promotion of the data element definitions and standard data vocabularies (SDV) will solve the application interoperability problem. Unfortunately, this intuitive understanding -- like many intuitive understandings -- doesn't survive the trials of real-life application because important (and seemingly trivial) assumptions are poorly conceived. This article will examine some of these assumptions and articulate several myths of 'standard' data semantics. The notion that data semantics can be standardized through the creation and promulgation of data element names/definitions or vocabularies is based on several assumptions that are actually myths: [1] Myth 1: Uniquely named data elements will enable, or are enough for, effective exchange of data semantics (i.e., information). [2] Myth 2: Uniquely named data elements will be used consistently by everybody to mean the same thing. [3] Myth 3: Uniquely named data elements can exist -- uniquely named as opposed to uniquely identified data elements. Many will readily acknowledge that these are, in fact, myths and that they don't really hold these assumptions. However, it seems that users of namespaces and developers of SDVs and metadata registries are pursuing their work as if these assumptions were true. No mechanisms or strategies have appeared in the extant literature that acknowledge, explain, or address the challenges that arise due to these faulty assumptions. The reasons that these assumptions are faulty fall into the following three areas of SDV development and use: (1) Scope, (2) Natural language use, and (3) Schema evolution... The purpose of this article hasn't been to argue that the problems and the challenges that face the SDV/registry development projects are unsolvable. Rather, it is to suggest that the solution vision must be more expansive. Faulty assumptions must be rooted out, and the problems that are thereby exposed must be explicitly and directly addressed. Despite their intuitive appeal, namespaces, SDVs, registries, and unique data element names will not solve the problem of interoperability. What's needed is the recognition that the semantics of a schema (or, more precisely, the semantics of data governed by a schema) must be explicitly bound to a known community that it serves, and that bridges between the communities will be an inevitable part of any comprehensive solution..." See: "XML and 'The Semantic Web'." [alt URL]

• [November 22, 2002] "The 19th Annual Awards for Technical Excellence. 'Protocols' Winners: SAML and WS-Security." By the Editors of PC Magazine. In PC Magazine (November 19, 2002). "Securing Web services is no easy task. The same virtues that make Web services so promising for e-business -- they're platform-independent, text-based, and self-describing -- create major security concerns, giving pause to businesses considering a move to the hot new interoperability technology. Two standards are emerging to secure Web services: Security Assertion Markup Language (SAML) and WS-Security, both proposals submitted to the Organization for the Advancement of Structured Information Standards (OASIS). To protect confidentiality, WS-Security relies on XML Encryption, while SAML uses the slower HTTPS. WS-Security protects individual transactions, and the substantial infrastructure required by SAML pays off with single sign-on capability. The Liberty Alliance's authentication solution -- Liberty 1.0 -- builds on SAML, while Microsoft's competing technology, .NET Passport, uses WS-Security. No matter whether these two standards converge or remain separate, the success of Web services in e-business could depend on them..." See: (1) "Web Services Security Specification (WS-Security)"; (2) "Security Assertion Markup Language (SAML)."

• [November 22, 2002] "Debug XSLT On The Fly: Debugging Tricks That Keep it Simple." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks, XML zone. November 2002. ['Debuggers are very handy in programming, but they can also be complex pieces of software in their own right -- complex to set up, to learn, and to use. Sometimes you just need a quick print-out of some values that you suspect to be at the heart of a specific problem you're seeing. In this article, Uche Ogbuji shows how to do quick debugging using xsl:message and other built-in facilities of XSLT, as well as common extensions in EXSLT.'] "Long before they turn to a debugger, most developers start with the equivalent of a print or printf statement in their programming language to try logging values that might shed some light on their code's errant behavior. XSLT is no exception. You can now get XSLT debuggers and even full integrated development environments (IDEs), but you probably won't always want to go through all the motions of firing up a debugger just to check a single value. This is especially true of those, like me, who use plain old XEmacs (with xslide, in my case) for editing XSLT transforms. xsl:message is usually the best solution for this. You can simply insert a message at the right spot in the right template as a quick debugging tool. The main downside is that there is no standard specification of xsl:message output: It can take the form of a pop-up dialog box, a log file, or -- for command-line XSLT processors -- a marked display to the standard error output. Usually, this is a minor matter; a quick trip to the documentation of any tool will tell you how it renders processor messages. Despite the potential differences in presentation, the nice thing about xsl:message is that it is a standard instruction and thus portable across processors. Here, I shall present several tips to make debugging with xsl:message even more effective..." For related resources, see "Extensible Stylesheet Language (XSL/XSLT)."

• [November 22, 2002] "W3C XML Schema Design Patterns: Avoiding Complexity." By Dare Obasanjo. From XML.com. November 20, 2002. ['A year or so ago XML.com published an article called "W3C XML Schema Made Simple," which suggested, somewhat controversially, that you should avoid areas of the W3C XML Schema specification in order to keep things manageable. This week our main feature is both a companion piece and counterpoint to the "Made Simple" article. In "W3C XML Schema Design Patterns: Avoiding Complexity" Dare Obasanjo suggests that most of W3C XML Schema is indeed useful, but highlights areas the schema author should handle with care.'] "Over the course of the past year, during which I've worked closely with W3C XML Schema (WXS), I've observed many schema authors struggle with various aspects of the language. Given the size and relative complexity of the WXS [W3C XML Schema] recommendation, it seems that many schema authors would be best served by understanding and utilizing an effective subset instead of attempting to comprehend all of its esoterica. There have been a few public attempts to define an effective subset of W3C XML Schema for general usage, most notable have been W3C XML Schema Made Simple by Kohsuke Kawaguchi and the X12 Reference Model for XML Design by the Accredited Standards Committee (ASC) X12. However, both documents are extremely conservative and advise against useful features of WXS without adequately describing the cost of doing so. This article is primarily a counterpoint to Kohsuke's and considers each of his original guidelines; the goal is to provide a set of solid guidelines about what you should do and shouldn't do when working with WXS... The Guidelines: I've altered some of Kohsuke's original guidelines [...] I propose some additional guidelines as well: Do favor key/keyref/unique over ID/IDREF for identity constraints; Do not use default or fixed values especially for types of xs:QName; Do not use type or group redefinition; Do use restriction and extension of simple types; Do use extension of complex types; Do carefully use restriction of complex types; Do carefully use abstract types; Do use elementFormDefault set to qualified and attributeFormDefault set to unqualified; Do use wildcards to provide well defined points of extensibility... The WXS recommendation is a complex specification because it attempts to solve complex problems. One can reduce its burdens by utilizing its simpler aspects. Schema authors should ensure that their schemas validate in multiple schema processors. Schemas are an important facilitator of interoperability. It's foolish to depend on the nuances of a specific implementation and inadvertently give up this interoperability..." General references in "XML Schemas."

• [November 22, 2002] "XML Versus the Infoset." By Rich Salz. From XML.com November 20, 2002. ['Rich Salz discusses the conflict between the notion of XML as syntax and XML as a collection of information items--the Infoset. This seemingly abstract matter has concrete repurcussions when it comes to digital signatures of SOAP messages'] "Cryptography is all about manipulating bytes; it's impossible to sign an Infoset, which must be, at some point, concretely represented. SOAP 1.2 currently allows processors a great deal of flexibility about whitespace between elements in the SOAP header; after all, in the SOAP processing model they're irrelevant Infoset items... If an entity can modify this whitespace, it's impossible to reliably sign a SOAP header: you have to create a signature that signs each individual header element. Which isn't the same thing, because you then need to synthesize an additional signed datum in order to prevent someone from adding a new element which isn't signed. In all fairness, the SOAP WG is working to address this by pointing out the problems and resurrecting a SOAP Canonicalization scheme I circulated last year. But we should be concerned that this issue has shown itself only now, while the SOAP specification is in last call. I can only wonder what will happen the next time XML and its Infoset come into conflict..."

• [November 22, 2002] "RPV: Triples Made Plain." By Kendall Grant Clark. From XML.com November 20, 2002. ['In the XML community over the past week, the debate over RDF rumbles on. As just about the oldest application of XML and Namespaces, the fact that RDF is still a source of debate four years later is testament to both its significance and its troubles. Kendall Grant Clark, custodian of the XML-Deviant column's watchful eye over the XML community, brings us the latest developments in the debate. Tim Bray has responded to the RDF discussion with a suggestion for a new RDF/XML syntax that aims to answer some of the criticisms of the existing format.'] "... If you don't like or understand or prefer RDF's XML serialization, find a way to avoid dealing with it directly. Using an RDF triplestore from a high-level language is one such way, while retaining some, perhaps all of the benefits of RDF's data model. So, my argument is a more focused variant of the suggestion Shelley Powers has been making repeatedly on XML-DEV lately: if you don't like or understand or prefer RDF, just don't use it. This seems fair enough. Most recent discussion of RDF, which has bubbled over the bounds of XML-DEV and moved out into the broader confines of the Web development community, has been by turns absurd and sublime. From foundational debates about whether RDF is complex, or fights over how to characterize its complexity, to awfully redundant discussions about whether its XML serialization is all that user-unfriendly, to meta-debates in which various sides jockey for position to see which side can be described as unfair or 'politically correct' (whatever that could possibly mean in this context) or dismissive or narrow-minded or high-handed -- and on and on. Yet the debate has also been productive at times, including Tim Bray's RPV proposal ['The RPV (Resource/Property/Value) Syntax for RDF']. Bray says his RPV proposal 'is an XML-based language for expressing RDF assertions ... designed to be entirely unambiguous and highly human-readable.' That two-part design goal is worth spending some time with insofar as it's emblematic of a good deal of the underlying debate over RDF. To say that an XML language is or should be 'entirely unambiguous' and 'highly human-readable' is to say that it should be as easily digestible by machines as by humans. It's that tension which runs all the way from XML to RDF. Further, Bray suggests that RDF has failed to gain traction because of this tension: his RPV proposal 'is motivated by a belief that RDF's problems are rooted at least in part in its syntax.' He elaborates on this point by saying, first, that RDF's XML serialization is 'scrambled and arcane,' preventing people from easily reading or writing it; second, that the XML serialization uses qualified names in a way that's not user-friendly and is in some conflict with the TAG's idea that significant resources be identified by URI; third, that there doesn't seem to be a general problem for metadata folks to think of things in terms of RDF's 3-tuples; fourth, that some alternatives to RDF-XML, like n3, suffer because, as non-XML, they can't get the network effect of ubiquitous XML support; and, fifth, that the idea of embedding RDF in XML languages, which seemed in the summer of 2000, both to Leigh Dodds and much of the rest of the XML development community, like a viable approach, 'has failed resoundingly in the marketplace'..." See "Resource Description Framework (RDF)."

• [November 22, 2002] "The RPV (Resource/Property/Value) Syntax for RDF." By Tim Bray. November 2002. ['The RPV (Resource/Property/Value) syntax is an XML-based language for expressing RDF assertions. It is designed to be entirely unambiguous and highly human-readable.'] "The Resource Description Framework (RDF) is designed to facilitate the interchange and processing of metadata concerning Resources (where the word Resource is used in its Web sense). RDF models metadata as 3-tuples which assert that some resource has some property (identified by URI) which has a value identified either by URI or given literally. The centrality of metadata in many classes of application, and the simplicity and elegance of RDF's data model would seem to make it something that has many obvious applications on the Web. Despite this, RDF has been slow to catch hold. The RPV language proposal is motivated by a belief that RDF's problems are rooted at least in part in its syntax. Specifically: (1) The syntax of RDF/XML is sufficiently scrambled and arcane that it is neither human-writeable nor human-readable. (2) The RDF/XML syntax makes heavy use of qnames that is neither intuitive to humans nor conforms particularly well to Web Architecture, which requires that everything significant be identified by URI. (3) People who care about metadata have no trouble thinking in terms of resource/property/value triples. (4) Alternatives like N3 that make the RDF triples evident in syntax suffer in comparison to the XML/RDF syntax because they lack XML's widely-deployed base of software, i18n facilities, and APIs. (5) The notion that you RDF can be mixed into XML transparently enough to be unobtrusive has failed resoundingly in the marketplace..." See John Cowan's summary: "Mini-review of Tim Bray's RPV syntax for RDF. This is mostly a remapping of a small subset of standard RDF/XML. It has the following features that RDF/XML has not: (1) Expresses property names as URIs rather than QNames; (2) String-valued property can have the string stored remotely, reachable by URL; (3) Incorporates xml:base; (4) Provides separate base attributes for resources, properties, and values..." See "Resource Description Framework (RDF)."

• [November 21, 2002] "Web Services Choreography Standard 18-24 Months Away." By Paul Krill. In InfoWorld (November 20, 2002). "Standardization of Web Services choreography, which will enable development of complex Web services for business, is 18 months to two years away, said a World Wide Web Consortium (W3C) official Wednesday while the W3C met to take up the issue. The complexity of the concept means it will take time to settle on a standard, said Sinisa Zimek, SAP advisory committee representative to W3C and a member of various W3C working groups. 'Choreography is a pretty broad area,' Zimek said 'It's much more complex to standardize choreographies than, for example, SOAP and WSDL.' Although WSDL and SOAP enable development of simple Web services such as stock quote notifications, more complicated Web services such as invoice processing will require choreography of processes, according to Zimek. The W3C this week held an event in Cambridge, MA... Upon conclusion of the advisory meeting, W3C members will continue until mid-December to provide input on a proposal to form a Web services choreography working group and afterward the director of the W3C, Tim Berners-Lee, will make a decision on whether to form such a panel, Zimek said. Members did concur that generally W3C should be the forum for standardizing Web services, according to Zimek. The panel is pondering the Sun-driven Web Services Choreography Interface (WSCI) proposal as a basis for Web services choreography and is waiting to hear from IBM and Microsoft on whether they will submit their rival plan, Business Process Extension Language for Web Services (BPEL4WS), to W3C for consideration as well, Zimek said. Zimek is an author of the WSCI specification..." See the draft W3C "Web Services Choreography Working Group Charter Proposal" posted by Jeff Mischkinsky on November 7, 2002 ["I have attached the proposed charter for a Choreography WG. This draft represents the WS Arch WG consensus recommendation that was taken on Nov 7, 2002..."] The discussion thread "Proposed Draft Charter for Choreography WG" provides additional background.

• [November 21, 2002] "Raising the Bar on RSS Feed Quality." By Timothy Appnel. From the O'Reilly Web Services DevCenter. November 19, 2002. "RSS is an XML-based syntax for facilitating the exchange of information in a lightweight fashion through the distribution (or feeding) of resources. Publishers can use this versatile and increasingly essential format to assist end users in tracking and consuming content. Netscape originally developed the format but lost interest and eventually abandoned work on it. This created an identity crisis that devolved into varying interruptions, with dispute over even the meaning of the RSS acronym, RDF Site Summary or Rich Site Summary or Really Simple Syndication. But as divergent efforts work to develop RSS, one result has been a diminished overall quality in RSS feeds. In this article, I provide an overview of RSS's core syntax, then I examine the poor state of RSS feed quality and provide some recommendations for authoring more useful and effective feeds. This examination is not a review of the RSS specification, nor is it an emphatic plea for strict compliance. Instead, this article provides an approach to authoring RSS feeds that is neutral, practical, and conservative. RSS feeds are simply too useful a mechanism for information exchange services. It is imperative that we improve their effectiveness..." See "RDF Site Summary (RSS)."

• [November 21, 2002] "Sun Presents XML Office Challenge." By [ComputerWire Staff]. In The Register (November 21, 2002). "Sun Microsystems Corp has floated a series of XML-based specifications designed to crack-open Microsoft Corp's Office monopoly and improve interoperability with StarOffice. Sun has lined-up partners to form a technical committee at the Organization for the Advancement of Structured Information Standards (OASIS) that will drive the proposed formats. Joining Sun are Corel Corp, XML publishing specialist Arbortext Inc, standards specialist Drake Certivo Inc and aircraft giant Boeing Corp among others... Sun said the OASIS Open Office XML Format Technical Committee's work would enable exchange of data in XML-based formats while retaining a 'high-level' of formatting between text, spreadsheets, charts and graphs... [Microsoft] Office's market share could come under pressure as customers, who are unhappy with Microsoft's latest licensing program, switch to low-cost offerings from rivals such as Sun and Corel. Microsoft, an OASIS member, said it sees 'no benefits' to joining as its customers will have 'great' XML support in its planned Office 11 product. Microsoft said the company supports XML Schema Datatypes (XSD) 1.0, and anything that the technical committee develops will work with Office 11. That version of the suite will use XSD 1.0. However, Joerg Heilig, Sun director of software engineering, said Sun's proposed formats do not use XSD 1.0. Heilig said they use 'standard' XML and existing standards such as Mathematical Mark-up Language (MathML) and Scalable Vector Graphics (SVG)..." See: "XML File Formats for Office Documents."

• [November 21, 2002] "OASIS Calls for OpenOffice XML Specification." By Margaret Kane. In ZDNet News.com (November 21, 2002). ['An array of companies working on Web services specifications is calling for a new open-source standard to handle desktop application documents.'] "... The working group is trying to develop a standard data format for the creation of content such as text, spreadsheets and charts. The goal is to develop an interface between the office software and other applications using XML (Extensible Markup Language). 'Our goal is to achieve consensus on an open standard that will protect content -- whether it is an 800-page airplane specification or a legal contract -- from being locked into a proprietary file format,' Michael Brauer, a Sun employee and chair of the OASIS Open Office XML Format Technical Committee, said in a statement. Microsoft, which controls more than 90 percent of the desktop application software market through its Office products, has decided to take a 'wait and see' approach with the working group, said Simon Marks, product manager for Office. Microsoft is an OASIS member, and can join the working group at a future date, he said. 'If this turns out to be something that we feel (is necessary) for customers we can join, but currently we'll just wait and see,' he said..." See: "XML File Formats for Office Documents."

• [November 20, 2002] "OASIS Aims to Create Office Document Standard." By Matt Berger. In InfoWorld (November 20, 2002). "A standards body known for creating key technologies around XML (Extensible Markup Language) said Wednesday that it has launched an effort to develop a standard file format that would allow office documents such as spreadsheets and word processing files to be opened by applications from different vendors... One of the goals of the group, called the Open Office XML Format Technical Committee, is to free corporate data from proprietary file formats so they can be accessed for years to come no matter what office software a company is using. Proponents contend that companies are currently saving data in proprietary file formats, such as those written in Microsoft's Word software, and locking themselves into using that software indefinitely. 'This solves a number of problems for enterprises,' said Simon Phipps, chief technology evangelist at Sun Microsystems, which is an initial member of the technical committee. 'It means that their data becomes machine readable without having to commit to a single vendor.' Corel Corp., which makes the word processing software Word Perfect, is also an initial member of the technical committee, and said it could benefit from such a standard. Other members include content management software maker Arbortext Inc. and The Boeing Co. Boeing has a stake in office document standards as it is bound by government regulations to create and archive an immense amount of data such as manuals. OpenOffice.org, the open source project that developed the office suite of the same name, has contributed its published list of XML-based office file formats to the group, with hopes that it will help provide the foundation for a standard. OpenOffice.org's software is sold by Sun as StarOffice... Creating an open office file format suggests that documents created in an application that supports that file format could be opened in other applications that support it as well. A document written using Corel Corp.'s Word Perfect, for example, could be opened in StarOffice without affecting the layout or formatting... Microsoft, which dominates the office software market with its Office suite, is a member of OASIS. Microsoft is aware of the technical committee but will not initially take part, a spokesman from a Microsoft outside public relations firm said in an e-mail message Wednesday. The company has announced recently that the next version of its Office suite, Office 11, will be heavily reliant on XML..." See: (1) the 2002-11-04 news item "OASIS Technical Committee for Open Office XML File Format"; (2) "OASIS Members Collaborate to Advance Open XML Format for Office Applications. Arbortext, Boeing, Corel, Drake Certivo, Sun Microsystems, and Others Develop Open Office Standard at Global Consortium."; (3) "XML File Formats for Office Documents."

• [November 20, 2002] "SAML 1.0 Signals Next Step in Evolution of Web Services Security. Industry Analysts Provide Insight on SAML's Role Among Other Prominent Security Standards." By Matt Migliore, James Kobielus (Senior Analyst, Burton Group) and Ray Wagner (Gartner Inc). In Enterprise Systems (November 20, 2002). ['SAML is an XML-based framework for Web services that allows the exchange of authentication and authorization information among independent networks. Through it, enterprises can enable a number of Web-based security functions -- such as single sign-on and role-based access control (RBAC) -- across sites hosted by multiple companies. Furthermore, SAML provides security functionality for more complex Web services integration, whereby Web services have the intelligence to reach out to a number of other components to perform a given task. Prior to its official 1.0 release, SAML had been receiving significant support among the vendor community. However, on the user side, SSL (Secure Sockets Layers) was being implemented to secure Web services, and another emerging standard, WS-Security, was also gaining momentum. Now that SAML 1.0 has been approved, it's unclear how these standards and others, such as Public Key Infrastructure (PKI), will fit into the Web services equation. To help answer some of these questions, Security Strategies held a brief Q&A session with James Kobielus, a senior analyst with Burton Group, and Ray Wagner, a research director with Gartner Inc.'] Excerpts from Kobielus: "...As an open Web services security standard with broad vendor support, SAML 1.0 will stimulate use of Web services for external integration among organizations' line-of-business applications (such as ERP and procurement). SAML 1.0 is one of the most fundamental interoperability standards for Web services security. Even in advance of the standard's formal ratification by OASIS, SAML 1.0 had already gained broad acceptance, adoption, and implementation by many vendors of Web services security products, especially vendors of Web access management platforms, including vendors such as IBM, Sun, Netegrity, Oblix, Entrust, Entegrity, and Novell... SAML 1.0 will not necessarily reinvigorate interest in or implementation of PKI beyond PKI's limited role in today's Web services environment. PKI is primarily used today to enable server-side SSL, and SAML will primarily leverage server-side SSL for secure sessions among SAML-enabled Web security platforms. Consequently, PKI will play a role -- albeit limited to server-side SSL -- in SAML implementations. But SAML does not require new or enhanced PKI capabilities, such as client-side SSL or digitally signed SAML assertions. And it's very unlikely that SAML implementors will layer these additional PKI capabilities on SAML-based Web services security environments when server-side SSL is sufficiently secure for most real-world applications, internal or external to organizations... SAML uses server-side SSL to support encryption of content flowing over HTTP/S sessions between SAML-enabled servers that are doing Web SSO and RBAC. What SAML offers over and above SSL is a SOAP-based messaging protocol for Web SSO, plus XML-based data structures -- known as SAML assertions -- that are exchanged between SAML-enabled servers over this messaging protocol, plus implementation profiles describing how users can transparently access SAML-based Web security services through standard Web browsers..." See: (1) "Security Assertion Markup Language (SAML) Version 1.0 an OASIS Open Standard"; (2) general references in "Security Assertion Markup Language (SAML)."

• [November 20, 2002] "Guidelines for the Use of XML within IETF Protocols." By Scott Hollenbeck (VeriSign, Inc.), Marshall T. Rose (Dover Beach Consulting, Inc), and Larry Masinter (Adobe Systems Incorporated) [WWW]. IETF Network Working Group, Internet-Draft. Reference: 'draft-hollenbeck-ietf-xml-guidelines-07.txt'. November 2, 2002, expires May 3, 2003. IETF Approved BCP. An IETF posting "Protocol Action: Guidelines for The Use of XML within IETF Protocols to BCP" indicates that this "Guidelines" document has been approved by The Internet Engineering Steering Group (IESG) as a "Best Current Practice (BCP)" publication; IESG contact persons are Ned Freed and Patrik Faltstrom. See background in the ietf-xml-use mailing list. "The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from the Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data in protocol exchanges... Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well... This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the 'best' or 'preferred' way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content. There are a number of protocol frameworks already in use or under development which focus entirely on 'XML protocol' -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP. The applicability of such protocols is not part of the scope of this document. In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks..." Note: The IETF BCP subseries of the RFC series "is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function..." [cache]

• [November 20, 2002] "OASIS at Work on Standard for Office Apps." By Peter Galli. In eWEEK (November 20, 2002). "The Organization for the Advancement of Structured Information Standards, or OASIS, has established a working group to create a standard data format for office applications that will improve data interoperability across those applications. OASIS, a not-for-profit consortium that drives the development and adoption of e-business standards, will announce on Wednesday the formation of the working group, known as the OASIS Open Office XML-Format Technical Committee. Sun Microsystems Inc.'s Michael Brauer will chair the committee, which includes representatives from Boeing, Corel Corp., Drake Certivo and Arbortext. Not on the initial list of initial technical committee members, however, is Microsoft Corp., although it is an OASIS member. Microsoft Office and Microsoft's other desktop office productivity applications account for more than 90 percent of that market. Simon Marks, a Microsoft office product manager, told eWEEK that the Redmond, Wash., company is not going to participate in the committee at this time... The technical committee will initially focus on standardizing data for content creation and then go on to simplifying data exchange between any XML application and office productivity applications. That will include business process automation, Web services, databases, search engines and other applications. Sun is also going to donate the XML file format specification utilized in the OpenOffice.org 1.0 project to the new OASIS technical committee as an input. 'The way these standards committees work is they take an initial input, which is then evolved. This file format is a suitable starting point as it's pure XML and fully specified by an open-source group,' Phipps said. An increasing number of companies are using proprietary formats and can only use a single-vendor platform for data. Accessing this often also uses brittle macro-languages built into the Web processing or Office tools themselves. 'They wanted a guarantee that their data would still be readable at an indefinite time in the future. So, with those three objectives in mind, the technical committee's intent is to create a standard data format that uses XML and which is fully specified so there are no surprises about what does what in the format,' Phipps said... While participation in the technical committee remains open to all organizations and individuals, OASIS said contributions will only be accepted if they are granted under perpetual, royalty-free, non-discriminatory terms. OASIS will also host an open mail-list for public comment, and completed work will be freely available to the public without licensing or other fees, the organization said..." See details in: (1) the 2002-11-04 news item "OASIS Technical Committee for Open Office XML File Format"; (2) "OASIS Members Collaborate to Advance Open XML Format for Office Applications. Arbortext, Boeing, Corel, Drake Certivo, Sun Microsystems, and Others Develop Open Office Standard at Global Consortium."; (3) "XML File Formats for Office Documents."

• [November 20, 2002] "Location, Location, Location-Based Services. Location-Based Security for Wireless Apps." By Harsha Srivatsa (Independent software consultant). From IBM developerWorks, Wireless Security. November 2002. ['Studies by industry analysts forecast even greater demand for wireless and mobile devices, creating substantial opportunities for wireless device application and service providers. Faced with an increasingly difficult challenge in raising both average revenue per user (ARPU) and numbers of subscribers, wireless carriers and their partners are developing a host of new products, services, and business models based on data services. We'll have a look at location-based services and how they boost both service and revenue.'] "Providers are gearing themselves to offer differentiated value added services through location-based services and commerce. Location-based services should play a major role in the evolution of wireless data services as well as provide significant revenue to mobile operators and content providers. The anticipated growth of location-based services necessitates our addressing information security issues, particularly for those applications that access valuable and proprietary information and perform sensitive operations, such as financial transactions. even though specifying security assertions in XML may not make much sense for a limited bandwidth wireless network, the advantages far outweigh its bandwidth overhead. XML is also the communication data format of choice for the new generation of open, interoperable Web services applications for security services. SAML provides a much-needed interoperability between compliant Web access management and security products for wireless applications. Adding location information for authentication and authorization to the existing wireless security mechanisms is a value-added proposition for information assurance..."

• [November 19, 2002] "Comdex: Open Mobile Alliance to Announce Eight Mobile Specs." By Ephraim Schwartz. In InfoWorld (November 19, 2002). "The OMA, Open Mobile Alliance, a cross-industry alliance between telecommunications and high tech, is expected to unveil a set of eight specifications for creating mobile applications and services. The OMA as a standard body governing the mobile industry is growing in importance as it adds new members and absorbs other mobile organizations. Over the last year, the OMA, which was founded by Nokia, Sun, Oracle, and others, admitted key rival Microsoft to its ranks and now totals 296 companies. 'You would be hard pressed to name any major company that is not in the OMA,' said Jacob Christfort, a vice chair on the OMA and CTO for Oracles Mobile Products and Services Division. The organization has also absorbed the WAP Forum, the Location Interoperabilty Forum, the MMS Interoperability Group, the SyncML Initiative, and the Wireless Village Initiative. The eight specifications that will be announced this week include the following: mobile browsing, Multimedia Messaging, Digital Rights Management, Domain Name Server lookup via mobile devices, mobile content download, e-mail push notification, and user/device profiles... One industry analyst called both the consolidation of groups and the release of specifications a boon to the industry giving developers a single set of standards. 'Up until now wireless middleware companies and application developers had to have membership in five different organizations and it was difficult to allocate resources,' said David Hayden, president of MobileWeek, in Palo Alto, Calif. The set of OMA standards if adhered to by all of the constituent players in the mobile industry will allow developers to basically write once and deploy an application across a plethora of devices including cell phones, handhelds, and converged devices. However, Hayden remains somewhat skeptical over the ability of the organization to house numerous rival companies. 'There could be some issues and