March 2001

• [March 31, 2001] DeltaXML XML Schema software. Posting from Robin LaFontaine describes online availability of 'schema comparator'. "Monsell's DeltaXML XML Schema software compares XML Schema files taking into account the fact that elements, attributes etc. can be in any order. So only significant changes are identified - even down to ignoring a change in the order of a 'choice' item, ... but a change in a 'sequence' is identified... The free trial version works for small schemas. If you want a full trial for larger schemas let me know and I will provide an evaluation license. If you have data files to compare, DeltaXML Markup will compare any XML files and identify changes for you, representing these changes in XML of course..." See the DTD changes in XML Schema from CR to PR, and XSU - Upgrade for XML Schema documents [20000922 to PR 20010316]. Also (1) "Revised Online Validator for XML Schema (XSV) and XML Schema Update Tool (XSU)" and (2) "XML Schemas."

• [March 30, 2001] "A Framework for Implementing Business Transactions on the Web." Hewlett-Packard initial submission to OASIS BTP work. By Dr. Mark Little (Transactions Architect, HP Arjuna Labs, Newcastle upon Tyne, England), with Dave Ingham, Savas Parastatidis, Jim Webber, and Stuart Wheater. 20 pages (with 11 notes). [See the posting from Mark Little.] "An increasingly large number of distributed applications are constructed by being composed from existing applications. The resulting applications can be very complex in structure, with complex relationships between their constituent applications. Furthermore, the execution of such an application may take a long time to complete, and may contain long periods of inactivity, often due to the constituent applications requiring user interactions. In a loosely coupled environment like the Web, it is inevitable that long running applications will require support for fault-tolerance, because machines may fail or services may be moved or withdrawn. A common technique for fault-tolerance is through the use of atomic transactions, which have the well know ACID properties, operating on persistent (long-lived) objects. Transactions ensure that only consistent state changes take place despite concurrent access and failures... From the previous discussions it should be evident that there are a range of applications that require different levels of transactionality. Many types of business transaction do not have the simple commit or rollback semantics of an ACID transaction, and may complete in a number of different ways that may still be interpreted as successful but which do not imply everything that the business transaction did has occurred. We have shown that a flexible and extensible framework for extended transactions is necessary, then in addition to standardising on the interfaces to this framework, we also need to work on specific extended transaction models that suit the Web. We would not expect applications to work at the level of Signals, Actions and SignalSets, as these are too low-level. Higher-level APIs are required to isolate programmers from these details. However, from experience we have found that this framework helps to clarify the requirements on specific extended transaction implementations. We have given examples of the types of Web applications that have different requirements on any transaction infrastructure, and from these we believe it should be possible to obtain suitable extended transaction models." Other issues that will need to be considered when implementing many business transactions include: (1) Security and confidentiality... (2) Audit trail... (3) Protocol completeness guarantee... (4) Quality of service..." See "OASIS Business Transactions Technical Committee."

• [March 30, 2001] "OASIS Security Services TC: Glossary." By the OASIS Security Services Technical Committee (SSTC). Edited by Jeff Hodges. "A New Oasis-SSTC-Draft is available from the on-line SSTC document repository. This draft is presently a work item of the Use Cases and Requirements subcommittee, and of the SSTC as a whole. This document comprises an overall glossary for the OASIS Security Services Technical Committee (SSTC) and its subgroups. Individual SSTC documents and/or subgroup documents may either reference this document and/or 'import' select subsets of terms." Background may be read in the mailing list archives (1) security-use and (2) security-services. Document also in PDF format. See the Technical Committee web pages.

• [March 30, 2001] "Spinning Your XML for Screens of All Sizes. Using HTML as an Intermediate Markup Language." By Alan E. Booth (Software Engineer, IBM) and Kathryn Heninger Britton (Senior Technical Staff Member, IBM). From IBM developerWorks. March 2001. ['This article shows how to use HTML as an intermediate language so that you can write a single stylesheet to translate from XML to one or more versions of HTML and use the features of the WebSphere Transcoding Publisher server to translate the resulting HTML to the target markup language the requesting device requires.'] "Business applications expressed in vertical XML dialects must be translated into presentation formats, such as HTML, to be displayed to users. With the advent of Internet-capable cell phones and wireless PDAs came several new presentation languages, many of which are in common use today. You can write XSLT stylesheets to control the way the original business-oriented XML data is translated into a presentation format, but the process of writing stylesheets for each different presentation of a single application is onerous. This article addresses two major trends in Web-based business applications: (1) The use of XML to capture business information without the presentation specifics of HTML. This trend is based on the recognition that the generation of business data requires different skills than the effective presentation of information. Also, business data is often exchanged by programs that find the presentation tagging irrelevant at best. (2) The proliferation of presentation markup languages and device constraints, multiplying the effort required to generate effective presentations. In addition to traditional desktop browsers, there are Internet-capable cell phones, PDAs, and pagers. These new devices often require different markup languages, such as compact HTML (CHTML), Wireless Markup Language (WML), VoiceXML, and Handheld Device Markup Language (HDML). In contrast to the rich rendering capabilities of desktop browsers, many of these devices have very constrained presentation capabilities, including small screens and navigation restrictions... IBM WebSphere Transcoding Publisher can transcode or translate automatically from HTML to several other presentation markup languages, including WML, HDML, and compact HTML (i-mode). Transcoding Publisher can also exploit the capability of XSLT to produce different output based on the values of parameters. It does so by deriving parameter values from the current request, using data in the HTTP header and characteristics of the requesting device. Using both of these capabilities, the problem of deriving multiple presentations from one business application can be reduced to generating one stylesheet that can produce one or more versions of the application in HTML, perhaps one full-featured version for desktop browsers, one medium-featured version for larger screen PDAs, and one for the most screen-constrained devices. Transcoding Publisher can then translate the selected content for the specific markup language of the target device."

• [March 30, 2001] "A Brief History of SOAP." By Don Box (DevelopMentor Inc.). March 30, 2001. "... For the most part, people have stopped arguing about SOAP. SOAP is what most people would consider a moderate success. The ideas of SOAP have been embraced by pretty much everyone at this point. The vendors are starting to support SOAP to one degree or another. There are even (unconfirmed) reports of interoperable implementations, but frankly, without interoperable metadata, I am not convinced wire-level interop is all that important. It looks like almost everyone will support WSDL until the W3C comes down with something better, so perhaps by the end of 3Q2001 we'll start to see really meaningful interop. SOAP's original intent was fairly modest: to codify how to send transient XML documents to invoke/trigger operations/responses on remote hosts. Because of our timing, we were forced to tackle issues that the schemas WG has since solved, which caused the S in SOAP to be somewhat lost. At this point in time, I firmly believe that only two things are needed for mid-term/long-term convergence: (1) The XML Schemas WG should address the issue of typed references and arrays. Adding support for these two 'synthetic' types would obviate the need for SOAP section 5. These constructs are broadly useful outside the scope of messaging/rpc applications, so it makes sense (to me at least) that the Schemas WG should address this. (2) Define the handful of additional constructs needed to tie the representational types from XML Schemas into operations and SUDS-style interfaces/WSDL-style portTypes. WSDL comes close enough to providing the necessary behavioral constructs to XML Schemas, and I am cautiously optimistic that something close to WSDL could subsume SOAP entirely. I strongly encourage you to study the WSDL spec and submit comments/improvements/errata so we can get convergence and interop in our lifetime..." See "Simple Object Access Protocol (SOAP)" and "Web Services Description Language (WSDL)."

• [March 30, 2001] "A Busy Developer's Guide to SOAP 1.1." By Dave Winer and Jake Savin (UserLand Software). March 28, 2001. "This specification documents a subset of SOAP 1.1 that forms a basis for interoperation between different environments much as the XML-RPC spec does. When we refer to 'SOAP' in this document we're referring to this subset of SOAP, not the full SOAP 1.1 specification. What is SOAP? For the purposes of this document, SOAP is a Remote Procedure Calling protocol that works over the Internet. A SOAP message is an HTTP-POST request. The body of the request is in XML. A procedure executes on the server and the value it returns is also formatted in XML. Procedure parameters and returned values can be scalars, numbers, strings, dates, etc.; and can also be complex record and list structures..." See also the political background [Dave's SOAP Journal, part 2] and the compatible validator running on SoapWare.Org. See "Simple Object Access Protocol (SOAP)."

• [March 30, 2001] "Expressing Qualified Dublin Core in RDF." Draft Version-2001-3-29. By Dublin Core Architecture Working Group. Authors: Stefan Kokkelink and Roland Schwänzl. Supersedes Guidance on expressing the Dublin Core within the Resource Description Framework (RDF). "In this draft Qualified Dublin Core is encoded in terms of RDF, the Resource Description Framework as defined by the RDF Model & Syntax Specification (XML namespace for RDF). RDF is a W3C recommendation. Also RDFS the RDF Schema specification 1.0 is used (XML namespace for RDFS). RDFS is a W3C candidate recommendation. Quite often the notion of URI (Uniform Resource Identifier) is used. The notion of URI is defined by RFC 2396 The notion of URI embraces URL and URN. We also discuss colaboration of qualified DC with other vocabularies and DumbDown. In this paper explicit encodings are provided for classical classification systems and thesauri. Additionally a procedure is discussed to create encodings for more general schemes. One of the majour changes with respect to the data model draft is the more systematic use of RDF Schema. It is understood that all DC related namespace references are currently in final call at the DC Architecture Working Group. They will be fixed in a forthcoming version of the current draft..." For related work, see CARMEN (Content Analysis, Retrieval and MetaData: Effective Networking) and especially CARMEN AP 6: MetaData based Indexing of Scientific Resources. See: "Dublin Core Metadata Initiative (DCMI)."

• [March 29, 2001] "XSLT Processor Benchmarks." By Eugene Kuznetsov and Cyrus Dolph. From XML.com. March 28, 2001. [The latest benchmark figures for XSLT processors show Microsoft's processor riding high, with strong performance from open source processors... XML.com is pleased to bring you the results of performance testing on XSLT processors. XSLT is now a vital part of many XML systems in production, and choosing the right processor can have a big impact. Microsoft's XSLT processor, shipped with their MSXML 3 library, comes top of the pile by a significiant margin. After Microsoft, there's a strong showing from the Java processors, with James Clark's XT--considered by many an "old faithful" among XSLT engines--coming ahead of the rest. Still, speed isn't everything, and most XSLT processors are incomplete with their implementation of the XSLT 1.0 Recommendation. On this score, Michael Kay's Saxon processor offers good spec implementation as well as respectable performance.'] "XSLTMark is a benchmark for the comprehensive measurement of XSLT processor performance. It consists of forty test cases designed to assess important functional areas of an XSLT processor. The latest release, version 2.0, has been used to assess ten different processors. This article describes the benchmark methodology and provides a brief overview of the results... The performance of XML processing in general is of considerable concern to both customers and engineers alike. With more and more XML-encoded data being transmitted and processed, the ability to both predict and improve XML performance is critical to delivering scalable and reliable solutions. While XSLT is a big part of delivering on the overall value proposition of XML (by allowing XML-XML data interchange and XML-HTML content presentation), it also presents the greatest performance challenge. Early anecdotal evidence showed wide disparities in real-life results, and no comprehensive benchmark tools were available to obtain more systematic assessments and comparisons... Of the processors included in this release of the benchmark, MSXML, Microsoft's C/C++ implementation, is the fastest overall. The three leading Java processors, XT, Oracle and Saxon, have surpassed the other C/C++ implementations to take 2nd through 4th place respectively. This suggests that high-level optimizations are more important than the implementation language in determining overall performance. The C/C++ processors tend to show more variation in their performance from test case to test case, scoring some very high marks alongside some disappointing performance. XSLTC aside, the C/C++ processors won first place in 33 of the 40 test cases, in some cases scoring two to three times as well as their Java competitors (attsets, dbonerow). This suggests that there is a lot of potential to be gained from using C/C++, but that consistent results might be harder to obtain..." Tool: XSLTMark; see also Kevin Jones' XSLBench test suite. For related resources, see "Extensible Stylesheet Language (XSL/XSLT)."

• [March 29, 2001] "XSLT Benchmark Results." By Eugene Kuznetsov and Cyrus Dolph. From XML.com. March 28, 2001. ['The full results from the DataPower XSLT processor benchmarks.'] XSLTMark gauges the capabilities of XSLT processing engines by testing them on a common platform with a variety of stylesheets and inputs that sample the gamut of possible applications. See the XSLTMark overview for more information about the benchmark itself and how to download it. These results were obtained by DataPower on a Pentium III/500 machine running Linux. We encourage XSLT engine authors and users to submit benchmark results on their platforms, as well as drivers for new processors. Test results for the following XSLT processors are available: Overall Chart; 4Suite 0.10.2 (Fourthought); Gnome XSLT 0.5.0 (Gnome Project); MSXML 3.0 (Microsoft); Oracle XSLT 2.0 (Oracle); Sablotron 0.51 (Ginger Alliance); Saxon 6.2.1 (Michael Kay); TransforMiiX 0.8 (Mozilla Project); Xalan-C++ 1.1 (Apache Project); Xalan-Java 2.0.0 (Apache Project); XSLTC alpha 4(Sun); XT 19991105 (James Clark); Key." See previous article. For related resources, see "Extensible Stylesheet Language (XSL/XSLT)."

• [March 29, 2001] "XML Q&A: DTDs, Industry Markup Languages, XSLT and Special Characters." By John E. Simpson. From XML.com. March 28, 2001. 'John Simpson solves hairy problems with DTDs and 'special characters.' John also provides some pointers on where to start with using industry markup languages.'

• [March 29, 2001] "XML-Deviant: Schemas by Example." By Leigh Dodds. From XML.com. March 28, 2001. ['There has been a lot of activity in the area of XML schema languages recently: with several key W3C publications and another community proposed schema language. Another alternative schema language has emerged from the XML community, relying entirely on example instance documents.'] (1) "W3C XML Schema: The finish line is now in sight for the members of the W3C XML Schemas Working Group. The XML Schema specifications are an important step closer to completion with their promotion to Proposed Recommendation status. All that remains now is for Tim Berners-Lee, as Director of the W3C, to approve the specifications before they become full Recommendations. The road has been long and hard, and it's had a number of difficult sections along the way." (2) Examplotron: "Eric van der Vlist has been helping to realize Rick Jelliffe's vision of a plurality of schema languages by publishing Examplotron, a schema language without any elements. Examplotron's innovation lies in its '"schema by example' approach to schema generation. Rather than define a dedicated schema language with which a document can be described, Examplotron uses sample instance documents, annotated with several attributes that carry schema specific information such as occurrence of elements, and assertions about element and attribute content. Like Schematron before it, Examplotron is implemented using XSLT. An Examplotron instance document can be converted into a validating stylesheet by applying a simple transformation..." For schema description and references, see "XML Schemas."

• [March 28, 2001] "No More Speaking In Code." By L. Scott Tillett. In InternetWeek (March 12, 2001). "An IT industry group has released specifications aimed at allowing business process-specific code in applications to be removed, shared and analyzed in much the same way data can be isolated from application logic. The language, called Business Process Modeling Language, is intended to let enterprises easily share business process details with suppliers and partners, diminishing the need to customize code when two businesses use the Internet for core processes such as monitoring inventory or manufacturing a product. If it's widely embraced, the standard would be used by software makers to break out business process code from their apps. The industry group behind the BPML specification calls itself the Business Process Management Initiative and includes more than 75 heavyweights including Computer Sciences Corp., Intalio, Nortel Networks, Sybase, Sun Microsystems, Blaze Software and Hewlett-Packard. Business Process Management Initiative members envision a day when business processes, like data, can reside in their own management systems -- where they can be analyzed to determine the best way of conducting business, or from which they might be passed along to business partners in a common language describing how a particular process should be performed. BPML, an 'object-oriented description of a process,' according to BPMI members, can be expressed in XML, making it easy for businesses to pass business-process specifications back and forth. 'BPML is a language for modeling processes both within and between businesses,' said Howard Smith, chief technology officer for BPMI member CSC." See (1) the announcement and (2) "Business Process Modeling Language (BPML)."

• [March 28, 2001] "[XML Transformations] Part 2: Transforming XML into SVG." By Doug Tidwell (Cyber Evangelist, developerWorks XML Team). From IBM developerWorks, XML Education. Updated: March 2001. ['The first section of our tutorial showed you how to transform XML documents into HTML. We used a variety of XML source documents (technical manuals, spreadsheet data, a business letter, etc.) and converted them into HTML. Along the way, we demonstrated the various things you can do with the XSLT and XPath standards. In this section, we'll use the World Wide Web Consortium's emerging Scalable Vector Graphics format (SVG) to convert a couple of our original documents into graphics.'] "For our transformations, we'll use two of our original six source documents: some spreadsheet data and a Shakespearean sonnet. The other documents from our original set aren't easily converted to SVG; we'll discuss why later... SVG is a language for describing two-dimensional graphics in XML. You use SVG elements to describe text, paths (sets of lines and curves), and images. Once you've defined those images, you can clip them, transform them, and manipulate them in a variety of interesting ways. In addition, you can define interactive and dynamic features by assigning event handlers, and you can use the Document Object Model (DOM) to modify the elements, attributes, and properties of the document. Finally, because SVG describes graphics in terms of lines, curves, text, and other primitives, SVG images can be scaled to any arbitrary degree of precision... We've taken a couple of our documents and transformed them into SVG. The column and pie charts are really useful examples that demonstrate what SVG can do, and our transformed sonnet displays the sonnet and its rhyme scheme clearly. These transformations used several important concepts in stylesheets. We used parameters and variables, we added extension functions when we needed them, and we used the mode attribute to control how templates were invoked. All of these were necessary because of the kind of documents we were creating. Despite this, our approach to writing stylesheets remains the same: (1) Determine the kind of document you want to create. (2) Look at the contents of that target document, and determine what information you need to complete it. (3) Build a stylesheet that creates the elements of the target document, and either retrieve or calculate the information you need for each part of the target document. The more text-intensive documents demonstrate what SVG doesn't do very well. Anything that contains text that needs to be broken into lines and paragraphs is difficult to do with SVG. You have to calculate the line breaks yourself, and you have to figure out how tall each line of text should be. Furthermore, if you wanted to use rich text features in your SVG document (display certain words in other fonts, different type sizes, different colors, etc.), your job would be even more difficult. See also tutorial articles (1) "Transforming XML into HTML" and (2) "Transforming XML into PDF." See: "W3C Scalable Vector Graphics (SVG)."

• [March 28, 2001] "Scalable Vector Graphics. [Integrated Design.]" By Molly E. Holzschlag. In WebTechniques Volume 6, Issue 4 (April 2001), pages 30-34. ['Scalable Vector Graphics is Up For Candidate Recommendation before the W3C. 'Will it be a Flash killer?' Wonders Molly E. Holzschlag.] "Scalable Vector Graphics (SVG) is a perfect example of technology and design meeting on a level playing field. Via XML markup, you can create and implement graphic images, animations, and interactive graphic designs for Web viewing. Of course, browsers must support SVG technology, which is one reason that many developers haven't looked into it too seriously, or perhaps haven't heard of it. SVG is being developed under the auspices of the W3C. As a result, developers have worked to make it compatible with other standards including XML, XSLT, CSS2, Document Object Model (DOM), SMIL, HTML 4.0, XHTML 1.0, and sufficient accessibility options via the Web Accessibility Initiative (WAI). As of this writing, SVG's status is Candidate Recommendation. The working group responsible for SVG has declared it stable, and if it passes several more tests, it moves into the Recommendation phase. Perhaps the most important concept to grasp when first studying SVG is its scalability. Graphics aren't limited by fixed pixels. Like vector graphics, you can make scalable graphics larger or smaller without distorting them. This is very important for designing across resolutions. Scalable graphics adjust to the available screen resolution. This alone makes SVG attractive to Web designers, as it solves one of the most frustrating issues we face: creating designs that are as interoperable, yet as visually rich, as possible... While SVG support in browsers obviously isn't immediately available, it's a technology that's worth watching and using. The fact that major companies are investing time and money to create tools that support it is indicative of the hope SVG holds. What's more, the fact that standards compliance is being written into these tools early on is very exciting -- an unprecedented event when it comes to client-side markup! So while SVG might not be something you'll actually use for awhile, it's absolutely worth taking out for a test drive, if only for the sheer fun of it." See: "W3C Scalable Vector Graphics (SVG)."

• [March 28, 2001] "An SVG Tool Kit for Java: Batik SVG Toolkit. [Product Review.]" By Clayton Crooks. In WebTechniques Volume 6, Issue 4 (April 2001), pages 40-41. ['Pros: Offers Java developers an easy way to add SVG capabilities to their programs. Cons: Unless you're developing custom solutions, apps are limited.'] "Batik, an open-source project lead by the Apache Software Foundation, is a Java-based tool kit for incorporating Scalable Vector Graphics (SVG) into applications. In addition to offering the developer tools that let you view, generate, or manipulate images, the Apache Software Foundation has released a set of applications with basic SVG functions that can be used with any standard application. The goal is to provide a complete set of core modules that can be used individually or together to develop SVG projects... Batik provides complete applications and modules, making it easy for Java-based applications to use SVG content. According to the Web site, using Batik's SVG Generator, you can develop a Java application to export any graphics format to the SVG format. Another application can be developed using Batik's SVG processor and Viewer to easily integrate SVG viewing capabilities. Still another application uses Batik's modules to convert SVG documents to various formats, such as popular raster formats like JPEG or PNG. Since its inception, Batik has been an open-source project. It was created when several groups working on independent SVG-related projects combined their efforts. The original teams included employees from industry giants like Eastman Kodak, Sun Microsystems, and IBM. The groups decided that their respective projects could benefit from the offerings of the others, and that combining the projects would result in a much more complete tool." See: "W3C Scalable Vector Graphics (SVG)."

• [March 28, 2001] "Zope: An Open-Source Web Application Server. [Review.]" By Brian Wilson (Harbro Systems in Santa Rosa, CA). In WebTechniques Volume 6, Issue 4 (April 2001), pages 80-81. 'Zope has rich set of content-management and database features; fairly steep learning curve.' "Many of the Web projects I work on are for nonprofit organizations, and I must lean heavily on volunteers who have little experience working on Web sites. As a result, I'm very interested in tools that help me set up and maintain a basic site layout, while letting beginners enter and maintain content. I heard that Zope could help me, so I decided to try it. Zope was developed by Digital Creations, which provides commercial support for it. The introduction to the online Zope Book says that Zope is a framework for building Web applications. It allows for powerful collaboration, simple content management, and Web component use. Sounds good so far. Because Zope is open source and runs on Red Hat Linux, I'll have access to updates and bug fixes. Zope is written in Python, making it portable across many platforms (www.python.org). Currently, it's available in binary format for Windows (9x/NT), Linux, and Solaris, plus it can be compiled on other Unix platforms. I used the pre-built Linux version for this article (Zope 2.2.4), which I tested on both versions 6.2 and 7.0 of Red Hat Linux... The heart of Zope is Document Template Markup Language (DTML). Yes, DTML requires that you learn yet another language, but it builds on HTML, so it should be familiar. It's also incredibly powerful. You can create pages through the Web interface, and use special Zope DTML tags to do things like iterate over the objects in a folder and insert them into a table. I began creating pages right away -- without knowing any DTML. . . Zope holds out the promise of being able to do everything I need for my Web sites. As with many open-source projects, Zope suffers from having a fabulously rich feature set that I cannot (yet) access because the documentation isn't finished. I know that in time, I could read through mailing list archives and scattered online docs to learn what I need to know, but that route is definitely no picnic. Although I found Zope impressive, I'm still fond of Apache. Hence, my next step will be to look at Midgard, which is based on Apache, MySQL, and PHP. It's definitely harder to install than Zope, but Midgard builds on the base of three tools I'm already using." See also "Zope Parsed XML Project Releases ParsedXML Version 1.0."

• [March 28, 2001] "Zope: Open Source Alternative for Content Management. Zope Proves Utility of Open-Source Web Tools." By Mark Walter and Aimee Beck. In The Seybold Report on Internet Publishing Volume 5, Number 7 (March 2001), pages 11-15. In depth review with case studies. ['SRIP looks at Zope, a free toolkit developed by Digital Creations that's gained favor among daily newspapers, corporations, government agencies and a host of Web startups. Included are details on Zope's new content-management framework, due out this spring.'] "With Net budgets plunging in parallel with the high-tech stock swoon, site managers are seeking lower-priced alternatives to premium content-management systems. That's good news for Digital Creations and Zope, its open-source Web publishing framework built on top of Python. This month Digital Creations is extending Zope even further, releasing a full-blown content-management system based on the Zope framework... Coming in the next release, due out later this spring, will be a simple syndication server that helps administrators set up automated polling for inbound feeds and lets authorized customers pull content for outgoing material. Also under development is an overhaul to the underlying presentation templates: Digital Creations plans to change its "document template markup language" and its reliance on custom tags to an XHTML-based scheme driven from custom attributes on standard tags. That change will make it much easier for template designers to get WYSIWYG feedback from within popular Web-design products, like Dreamweaver or GoLive... Every system has its limitations, and Zope, for all its power and flexibility, relies on Python, which at this point is not yet the language of the masses. The upside, of course, is that Zope is open source: If you're willing to roll up your sleeves, you can save considerable money on software. In following Linux, Digital Creations has confirmed the merits of the open source software model and garnered supporters from across the globe. With CMF, Digital Creations has taken a big step toward bringing Zope to an even wider audience. The downside to open-source products, compared to their commercial counterparts, is that users have to assume primary responsibility for support. In the Zope CMF, customers get a nice combination -- free code, and, in Digital Creations, a consultant with deep experience solving complex publishing problems. At a time when Web budgets are being trimmed, but the volume of content continues to rise, Zope could be poised for even faster growth. Fredericksburg.com's Muldrow concludes, 'I've honestly not seen a product that so completely improved the way we do things -- I built a product to post jobs online in less than a day. We haven't been able to do that with anything else'." See also "Zope Parsed XML Project Releases ParsedXML Version 1.0."

• [March 28, 2001] "Trailblazing with XPath. [XML@Large.]" By Michael Floyd. In WebTechniques Volume 6, Issue 4 (April 2001), pages 66-69. ['XPath will keep you from getting lost in your document trees whether you're using XSLT or the DOM. Michael Floyd provides guidance.'] "As in desert enduro, finding your way through XML documents isn't always a straightforward task. Fortunately, the designers of XML have included a mechanism, called XPath, that helps you navigate through documents. XPath partly defines a syntax that lets you easily traverse a tree's structure and select one or more of its nodes. Once you've selected a node or nodes, you can manipulate, reorder, or transform them in any way you desire. The mechanism that lets you select tree nodes is called a pattern. A pattern is actually a limited form of what XPath calls location paths. (We'll get to location paths in a moment.) Much of XPath's expression language was originally described in the early XSL specification. Eventually, however, the W3C broke the XSL specification into three parts: XSL, which describes the formatting objects used to display XML elements; the XSL Transformation Language, which lets you transform XML into other formats; and XPath. So it's easy to associate XPath expressions with XSLT. It turns out, however, that these expressions are also useful in other tree-related models, including the Document Object Model (DOM) and XPointer. You can also use XPath expressions as arguments to DOM function calls... Of course, there's a great deal more to XPath than I've described here. In future months, I'll cover the other functions, including number, Boolean, and node-set functions. More importantly, I'll show you how to use them in DOM work and in creating style sheets."

• [March 27, 2001] "ebXML Specification Released for Public Review." By Michael Meehan. In InfoWorld (March 27, 2001). "Starting this week, the public will be able to get a detailed look at what could be the key to unifying the fragmented world of business-to-business e-commerce, as the public review of electronic business XML (ebXML) gets under way. Included in the standard will be protocols to handle transport routing, trading partner agreements, security, document construction, naming conventions, and business process integration -- the soup-to-nuts menu for online commerce. More than 2,000 people from 30-plus countries have helped develop the ebXML specifications, which are set for final approval in Vienna in May. Behind the 18-month effort are a United Nations e-business trade bureau called UN/CEFACT and a consortium called the Organization for the Advancement of Structured Information Standards, or OASIS. The standards group was led by executives from IBM, Sun, and Microsoft, which contributed some late but important input. The ebXML organizing body last month agreed to incorporate the transport sequence for the Microsoft-backed Simple Object Access Protocol (SOAP), making it far easier for businesses to swap information. SOAP is Microsoft's sole contribution to date. The addition of SOAP is 'a tremendous plus for us,' said Neal Smith, an IT architect at Chevron in San Francisco. 'We have a lot of Microsoft technology, and we like anything that makes it easier for us to use the stuff we have.' He said he hopes ebXML will set basic standards that oil industry exchanges can then build upon. 'Ideally, you can just take the parts you need and leave out the ones you don't, without disrupting anything,' Smith said. T. Kyle Quinn, director of e-business information systems at Boeing in Seattle, has also been involved in the ebXML standard. He argued that users must steer the standard's development. 'The Unix/Windows debate is still alive, and one of the things we want to do is drive the standards discussion to make it go away,' Quinn said. 'The point of e-commerce is we're all supposed to be working together, and it's crucial to keep the standards open.' Most of the work is now done. What remains to be seen is how the public will react..." See "Electronic Business XML Initiative (ebXML)."

• [March 24, 2001] "A Web Odyssey: From Codd to XML. [Invited Presentation.]" By Victor Vianu (UC San Diego). With 100 references. (so!) Paper presented at PODS 2001. Twentieth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS). May 21 - 24, 2001. Santa Barbara, California, USA. "What does the age of the Web mean for database theory? It is a challenge and an opportunity, an exciting journey of rediscovery. These are some notes from the road... What makes the Web scenario different from classical databases? In short, everything. A classical database is a coherently designed system. The system imposes rigid structure, and provides queries, updates, as well as transactions, concurrency, integrity, and recovery, in a controlled environment. The Web escapes any such control. It is a free-evolving, ever-changing collection of data sources of various shapes and forms, interacting according to a exible protocol. A database is a polished artifact. The Web is closer to a natural ecosystem. Why bother then? Because there is tremendous need for database-like functionality to efficiently provide and access data on the Web and for a wide range of applications. And, despite the differences, it turns out that database knowhow remains extremely valuable and effective. The design of XML query and schema languages has been heavily influenced by the database community. XML query processing techniques are based on underlying algebras, and use rewrite rules and execution plans much like their relational counterparts. The use of the database paradigm on the Web is a success story, a testament to the robustness of databases as a field. Much of the traditional framework of database theory needs to be reinvented in the Web scenario. Data no longer fits nicely into tables. Instead, it is self-describing and irregular, with little distinction between schema and data. This has been formalized by semi-structured data. Schemas, when available, are a far cry from tables, or even from more complex object-oriented schemas. They provide much richer mechanisms for specifying exible, recursively nested structures, possibly ordered. A related problem is that of constraints, generalizing to the semi-structured and XML frameworks classical dependencies like functional and inclusion dependencies. Specifying them often requires recursive navigation through the nested data, using path expressions. Query languages also differ significantly from their relational brethren. The lack ofschema leads to a more navigational approach, where data is explored from specific entry points. The nested structure of data leads to recursion in queries, in the form of path expressions. Other paradigms have also proven useful, such as structural recursion... One of the most elegant theoretical developments is the connection of XML schemas and queries to tree automata. Indeed, while the classical theory of queries languages is intimately related to finite-model theory, automata theory has instead emerged as the natural formal companion to XML. Interestingly, research on XML is feeding back into tree automata theory and is re-energizing this somewhat arcane area of language theory. This connection is a recurring theme throughout the paper... In order to meaningfully contribute to the formal foundations of the Web, database theory has embarked upon a fascinating journey of rediscovery. In the process, some of the basic assumptions of the classical theory had to be revisited, while others were convincingly reaffirmed. There are several recurring technical themes. They include extended conjunctive queries, limited recursion in the form of path expressions, ordered data, views, incomplete information, active features. Automata theory has emerged as a powerful tool for understanding XML schema and query languages. The specific needs of the XML scenario have inturn provided feedback into automata theory, generating new lines of research. The Web scenario is raising an unprecedented wealth of challenging problems for database theory -- a new frontier to be explored."

• [March 24, 2001] "On XML Integrity Constraints in the Presence of DTDs." By Wenfei Fan (Bell Labs and Temple University), and Leonid Libkin (University of Toronto). Paper presented at PODS 2001. Twentieth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS). May 21 - 24, 2001. Santa Barbara, California, USA. With 32 references. "Abstract: "The paper investigates XML document specifications with DTDs and integrity constraints, such as keys and foreign keys. We study the consistency problem of checking whether a given specification is meaningful: that is, whether there exists an XML document that both conforms to the DTD and satisfies the constraints. We show that DTDs interact with constraints in a highly intricate way and as a result, the consistency problem in general is undecidable. When it comes to unary keys and foreign keys, the consistency problem is shown to be NP-complete. This is done by coding DTDs and integrity constraints with linear constraints on the integers. We consider the variations of the problem (by both restricting and enlarging the class of constraints), and identify a number of tractable cases, as well as a number of additional NP-complete ones. By incorporating negations of constraints, we establish complexity bounds on the implication problem, which is shown to be coNP-complete for unary keys and foreign keys." Detail: Although a number of dependency formalisms were developed for relational databases, functional and inclusion dependencies are the ones used most often. More precisely, only two subclasses of functional and inclusion dependencies, namely, keys and foreign keys, are commonly found in practice. Both are fundamental to conceptual database design, and are supported by the SQL standard. They provide a mechanism by which one can uniquely identify a tuple in a relation and refer to a tuple from another relation. They have proved useful in update anomaly prevention, query optimization and index design. XML (eXtensible Markup Language) has become the prime standard for data exchange on the Web. XML data typically originates in databases. If XML is to represent data currently residing in databases, it should support keys and foreign keys, which are an essential part of the semantics of the data. A number of key and foreign key specifications have been proposed for XML, e.g., the XML standard (DTD), XML Data, and XML Schema. Keys and foreign keys for XML are important in, among other things, query optimization, data integration, and in data exchange for converting databases to an XML encoding. XML data usually comes with a DTD that specifies how a document is organized. Thus, a specification of an XML document may consist of both a DTD and a set of integrity constraints, such as keys and foreign keys. A legitimate question then is whether such a specification is consistent, or meaningful: that is, whether there exists a (finite) XML document that both satisfies the constraints and conforms to the DTD. In the relational database setting, such a question would have a trivial answer: one can write arbitrary (primary) key and foreign key specifications in SQL, without worrying about consistency. However, DTDs (and other schema specifications for XML) are more complex than relational schemas: in fact, XML documents are typically modeled as node-labeled trees, e.g. in XSL, XQL, XML Schema, XPath, and DOM. Consequently, DTDs may interact with keys and foreign keys in a rather nontrivial way, as will be seen shortly. Thus, we shall study the following family of problems, where C ranges over classes of integrity constraints... We have studied the consistency problems associated with four classes of integrity constraints for XML. We have shown that in contrast to its trivial counterpart in relational databases, the consistency problem is un- decidable for C[K,FK], the class of multi-attribute keys and foreign keys. This demonstrates that the interac- tion between DTDs and key/foreign key constraints is rather intricate. This negative result motivated us to study C{Unary}[K,FK], the class of unary keys and foreign keys, which are commonly used in practice. We have developed a characterization of DTDs and unary constraints in terms of linear integer constraints. This establishes a connection between DTDs, unary constraints and linear integer programming, and allows us to use techniques from combinatorial optimization in the study of XML constraints. We have shown that the consistency problem for C{Unary}[K,FK] is NP-complete. Furthermore, the problem remains in NP for C{Unary}[K-neg,IC-neg], the class of unary keys, unary inclusion constraints and their negations. We have also investigated the implication problems for XML keys and foreign keys. In particular, we have shown that the problem is undecidable for C[K,FK] and it is coNP-complete for C{Unary}[K,FK] constraints. Several PTIME decidable cases of the implication and consistency problems have also been identified. The main results of the paper are summarized in Figure 4. It is worth remarking that the undecidability and NP-hardness results also hold for other schema specifications beyond DTDs, such as XML Schema and the generalization of DTDs proposed in [Y. Papakonstantinou and V. Vianu. 'Type inference for views of semistructured data']. This work is a first step towards understanding the interaction between DTDs and integrity constraints. A number of questions remain open. First, we have only considered keys and foreign keys defined with XML attributes. We expect to expand techniques developed here for more general schema and constraint specifications, such as those proposed in XML Schema and in a recent proposal for XML keys. Second, other constraints commonly found in databases, e.g., inverse constraints, deserve further investigation. Third, a lot of work remains to be done on identifying tractable yet practical classes of constraints and on developing heuristics for consistency analysis. Finally, a related project is to use integrity constraints to distinguish good XML design (specification) from bad design, along the lines of normalization of relational schemas. Coding with linear integer constraints gives us decidability for some implication problems for XML constraints, which is a first step towards a design theory for XML specifications." Note the longer version of the paper referenced on Wenfei Fan's web site. [cache]

• [March 24, 2001] "XML with Data Values: Typechecking Revisited." By Noga Alon (Tel Aviv University), Tova Milo (Tel Aviv University), Frank Neven (Limburgs Universitair Centrum), Dan Suciu (University of Washington), and Victor Vianu (UC San Diego). Paper presented at PODS 2001. Twentieth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS). May 21 - 24, 2001. Santa Barbara, California, USA. Abstract: "We investigate the typechecking problem for XML queries: statically verifying that every answer to a query conforms to a given output DTD, for inputs satisfying a given input DTD. This problem had been studied by a subset of the authors in a simplified framework that captured the structure of XML documents but ignored data values. We revisit here the typechecking problem in the more realistic case when data values are present in documents and tested by queries. In this extended framework, typechecking quickly becomes undecidable. However, it remains decidable for large classes of queries and DTDs of practical interest. The main contribution of the present paper is to trace a fairly tight boundary of decidability for typechecking with data values. The complexity of typechecking in the decidable cases is also considered." Details: "Databases play a crucial role in new internet applications ranging from electronic commerce to Web site management to digital government. Such applications have redefined the technological boundaries of the area. The emergence of the Extended Markup Language (XML) as the likely standard for representing and exchanging data on the Web has confirmed the central role of semistructured data but has also redefined some of the ground rules. Perhaps the most important is that XML marks the 'return of the schema' (albeit loose and flexible) in semistructured data, in the form of its Data Type Definitions (DTDs), which constrain valid XML documents. The benefits of DTDs are numerous. Some are analogous to those derived from schema information in relational query processing. Perhaps most importantly to the context of the Web, DTDs can be used to validate data exchange. In a typical scenario, a user community would agree on a common DTD and on producing only XML documents which are valid with respect to the specified DTD. This raises the issue of (static) typechecking: verifying at compile time that every XML document which is the result of a specified query applied to a valid input document, satisfies the output DTD... On the decidability side, we show that typechecking is decidable for queries with non-recursive path expressions, arbitrary input DTD, and output DTD specifying conditions on the number of children of nodes with a given label. We are able to extend this to DTDs using star-free regular expressions, and then full regular expressions, by increasingly restricting the query language. We also establish lower and upper complexity bounds for our typechecking algorithms. The upper bounds range from pspace to non-elementary, but it is open if these are tight. The lower bounds range from co-np to pspace . On the undecidability side, we show that typechecking be- comes undecidable as soon as the main decidable cases are extended even slightly. We mainly consider extensions with recursive path expressions in queries, or with types decoupled from tags in DTDs (also known as specialization). This traces a fairly tight boundary for the decidability of typechecking with data values... The main contribution of the present paper is to shed light on the feasibility of typechecking XML queries that make use of data values in XML documents. The results trace a fairly tight boundary of decidability of typechecking. In a nutshell, they show that typechecking is decidable for XML-QL-like queries without recursion in path expressions, and output DTDs without specialization. As soon as recursion or specialization are added, typechecking becomes undecidable..." [cache]

• [March 24, 2001] "Representing and Querying XML with Incomplete Information." By Serge Abiteboul (INRIA), Luc Segoufin (INRIA), and Victor Vianu (UC San Diego). Paper presented at PODS 2001. Twentieth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS). May 21 - 24, 2001. Santa Barbara, California, USA. With 25 references. Abstract: "We study the representation and querying of XML with incomplete information. We consider a simple model for XML data and their DTDs, a very simple query language, and a representation system for incomplete information in the spirit of the representations systems developed by Imielinski and Lipski for relational databases. In the scenario we consider, the incomplete information about an XML document is continuously enriched by successive queries to the document. We show that our representation system can represent partial information about the source document acquired by successive queries, and that it can be used to intelligently answer new queries. We also consider the impact on complexity of enriching our representation system or query language with additional features. The results suggest that our approach achieves a practically appealing balance between expressiveness and tractability. The research presented here was motivated by the Xyleme project at INRIA, whose objective it is to develop a data warehouse for Web XML documents... The main contribution of this paper is a simple framework for acquiring, maintaining, and querying XML documents with incomplete information. The framework provides a model for XML documents and DTDs, a simple XML query language, and a representation system for XML with incomplete information. We show that the incomplete information acquired by consecutive queries and answers can be effciently represented and incrementally refined using our representation system. Queries are handled effciently and exibly. They are answered as best possible using the available information, either completely, orby providing an incomplete answer using our representation system. Alternatively, full answers can be provided by completing the partial information using additional queries to the sources, guaranteed to be non-redundant. Our framework is limited in many ways. For example, we assume that sources provide persistent node ids. Order in documents and DTDs is ignored, and is not used by queries. The query language is very simple, and does not use recursive path expressions and data joins. In order to trace the boundary of tractability, we considered several extensions to our framework and showed that they have significant impact on handling incomplete information, ranging from cosmetic to high complexity or undecidability. This justifies the particular cocktail of features making up our framework, and suggests that it provides a practically appealing solution to handling incomplete information in XML." See: "Xyleme Project: Dynamic Data Warehouse for the XML Data of the Web." [cache]

• [March 24, 2001] "Xyleme, une start-up de l'Inria pour structurer le Web en XML." From 01net.com. March 01, 2001. Xyleme veut structurer les données sémantiques du Web en XML. Objectif? Construire un moteur de recherche professionnel, interrogeable à partir du systhme d'information de l'entreprise." ["The Web is moving from HTML to XML, with all the major players, Microsoft, IBM, Oracle, content providers, B2B enablers, behind this revolution. Xyleme exploits this revolution to create a new service through an indexed XML repository that stores Web knowledge and that is capable of answering queries from applications and users. The outcome is a seamless integration between the web and corporate information systems... Xyleme is designed to store, classify, index and monitor XML data on the Web. The emphasis is on high level services that are difficult or impossible to support with the current Web technologies. In particular, we consider more complex query processing than the simple keyword search of actual search engines, semantic data integration and sophisticated monitoring of changes..."] See: "Xyleme Project: Dynamic Data Warehouse for the XML Data of the Web."

• [March 24, 2001] "SCHUCS: A UML-Based Approach for Describing Data Representations Intended for XML Encoding." By Michael Hucka (Systems Biology Workbench Development Group ERATO Kitano Systems Biology Project). 'Version of 11 December 2000'. UML to XML Schema mappings. Note: this document supplements the SBML Level 1 final specification, which uses a simple UML-based notation to describe the data structures: Systems Biology Markup Language (SBML) Level 1: Structures and Facilities for Basic Model Definitions." See the corresponding news item on SBML. "There are three main advantages to using UML class diagrams as a basis for defining data structures. First, compared to using other notations or a programming language, the UML visual representations are generally easier to read and understand by readers who are not computer scientists. Second, the visual notation is implementation-neutral -- the defined structures can be encoded in any concrete implementation language, not just XML but other formats as well, making the UML-based definitions more useful and exible. Third, UML is a de facto industry standard, documented in many books and available in many software tools including mainstream development environments (such as Microsoft Visual Basic 5 Enterprise Edition). Readers are therefore more likely to be familiar with it than other notations. Readers do not need to know UML in advance; this document provides descriptions of all the constructs used. The notation presented here can be expressed not only in graphical diagram form (which is what UML is all about) but also in textual form, allowing descriptions to be easily written in a text editor and sent as plain-text email. The scope of the notation is limited to classes and their attributes, not class methods or operations. One of the goals of this effort has been to develop a consistent, systematic method for translating UML-based class diagrams into XML Schemas. Another goal has been to maintain a reasonably simple notation and UML-to-XML mapping. An important side-effect of this is that the vocabulary of the notation is purposefully limited to only a small number of constructs. It is explicitly not intended to cover the full power of UML or XML. This limited vocabulary has nevertheless been sufficient for the applications to which it has been applied so far in the Systems Biology workbench project... The notation proposed in this document is based on a subset of what could be used and what UML provides. It is not intended to cover the full scope of UML or XML. The subset was chosen to be as simple as possible yet allow the expression of the kinds of data structures that need to be encoded in XML for the ERATO Kitano Systems Biology workbench. The notation proposed here is not carved in stone, and will undoubtedly continue to evolve..." See: "Systems Biology Markup Language (SBML)." [cache]

• [March 24, 2001] "RDF Protocol." By Ken MacLeod. March 24, 2001. "RDF Protocol is simple structured text alternative to standard ASCII line-oriented protocol (as used in FTP, NNTP, SMTP, et al.). RDF Protocol also subsumes the features of RFC-822-style headers as used in MIME, SMTP, and HTTP." Includes Core RDF Protocol; IRC in RDF Protocol; Replication in RDF Protocol. [From the posting: 'Toying With an Idea: RDF Protocol': "RDF Protocol really isn't a protocol so much as setting down some conventions for passing bits of RDF around. Well, ok, some of the bits work a lot like a protocol, so it's gotta look like that, but here goes... I'm playing with a Python implementation of the basic message read/write and using IRC as the example protocol to emulate, using Dave Beckett's IRC in RDF schema. In case anyone was wondering, there are no APIs and no RPCs at this layer, it's all XML instance passing, with RDF triples as the content..." See "Resource Description Framework (RDF)."

• [March 24, 2001] "DocBook TREX Schema V4.1.2.2." From Norman Walsh. 03-12-01. DocBook TREX Schema V4.1.2.2 "is the current experimental TREX Schema version of DocBook. This version was (mostly) generated automatically from the RELAX version. This version is available as a zip archive. Includes: docbook.trex (the DocBook TREX Schema); dbhier.trex (the DocBook TREX Schema 'hierarchy' module); dbpool.trex (the DocBook TREX Schema 'information pool' module); dbtables.trex (the DocBook TREX Schema tables module); text.xml (a test document). See: "Tree Regular Expressions for XML (TREX)." Also: (1) RELAX DocBook schema; (2) W3C XML DocBook schema. [cache]

• [March 24, 2001] "SOAP Toolkit 2.0: New Definition Languages Expose Your COM Objects to SOAP Clients." By Carlos C. Tapang. From MSDN Online. March 20, 2001, "April 2001" issue. ['This article describes a custom tool, IDL2SDL, which takes an IDL file and produces Web Services Description Language (WSDL) and Web Services Meta Language (WSML) files without waiting for a DLL or TLB file to be generated. This article assumes you're familiar with XML, SOAP, COM, and Visual C++.'] "In SOAP Toolkit 2.0, the Services Description Language (SDL) has been replaced with the Web Services Description Language (WSDL) and the Web Services Meta Language (WSML). WSDL and WSML files describe the interfaces to a service and expose COM objects to SOAP clients. This article describes a custom tool, IDL2SDL, which takes an IDL file and produces WSDL and WSML files without waiting for a DLL or TLB file to be generated. Also shown is a customized development environment in which WSDL and WSML files automatically reflect the changes to IDL files... When the November 2000 release of the Microsoft SOAP Toolkit 1.0 became widely available, I wrote an Interface Description Language (IDL) to Service Description Language (SDL) translator, which I named IDL2SDL. Since SDL has been replaced with Web Services Description Language (WSDL) and Web Services Meta Language (WSML) in version 2.0 of the SOAP Toolkit, I have rewritten the translator to support WSDL and WSML. In this article I will explain how to use the translator and introduce version 2.0 of the SOAP Toolkit. You will get to know IDL2SDL and learn how to incorporate it into your development environment. The tool is available at http://www.infotects.com/IDL2SDL, together with a very simple C++ sample COM object on the server side and a Visual Basic-based app on the client side. This tool is free, and I welcome questions and suggestions for improvement. The WSDL and WSML files describe the interfaces to your service and expose your COM object to SOAP clients. The SOAP Toolkit already provides the WSDLGenerator tool. The generator derives the service description from the object's TypeLib. (TypeLib is usually embedded in the DLL file in which a COM component resides.) Whereas the WSDLGenerator tool is very well-suited for situations in which you only want to reuse available components in a Web service, the IDL2SDL tool is more appropriate for situations in which you are designing your server components completely from the ground up. During development, interface specifications can change often, even during testing. The IDL2SDL utility allows you to change your IDL file and produce both WSDL and WSML files without having to wait for the DLL or TLB file to be generated. You can set up your development environment with IDL2SDL such that your WSDL and WSML files automatically reflect the changes to your IDL file. In a later section, I will describe the simple steps you need to take to make IDL2SDL part of the Visual Studio development environment. Since SOAP is designed to be universal, it is applicable to remote procedure call component architectures other than COM. Likewise, IDL can express interface contracts for component architectures other than COM. There is no standard for IDL, but IDL2SDL can be modified to easily accommodate inputs for the Microsoft MIDL and for the DCE IDL compiler... The sample Web service shown here demonstrates that version 2.0 of the SOAP Toolkit is a completely different implementation from version 1.0. However, it is just as easy to use. Like version 1.0, version 2.0 accommodates both users who just want to expose their COM object to SOAP and users who have a need to generate the SOAP messages. The IDL2SDL tool even makes it easier by automating the production of WSDL, WSML, and ASP files. The IDL2SDL tool is freely available, but it is not part of the SOAP Toolkit. This tool was built using the Flex lexical analyzer and the BISON parser generator, which are available from http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html. The sample files and tools are also available from the Infotects Web site." [Note: the SOAP Toolkit 2.0 Beta 2 available for download has "several major enhancements, including a new ISAPI listener and support for simple arrays."] See: "Web Services Description Language (WSDL)."

• [March 24, 2001] "XML Web Service-Enabled Office Documents." By Chris Lovett. In MSDN Column 'Extreme XML'. March 22, 2001. ['Chris Lovett explores Office XP and .NET Web Services, and how you can use them together to deliver powerful desktop solutions for your business.'] "Are you ready for a marriage of Microsoft Office XP and .NET Web Services? In a networked world of B2B e-commerce, why not deliver the power of Web Services to the end user by integrating business process workflow right into everything people do from their desktop? What am I talking about? Well, an Excel spreadsheet that looks something like [Figure 1]... This is not just an ordinary spreadsheet. It uses UDDI to find company addresses and it uses a Catalog Web Service to find product information. It also does an XML transform on the XML spreadsheet format to generate a RosettaNet PIP 3 A4 Purchase Order Request format when you click the Send button. When you type in the name of the company you are purchasing from, and then click on the Find button, some VBA code behind the spreadsheet makes a UDDI call and fills out the rest of the address section... When you type in a quantity of, say, 23, in the 'Purchase From" field and then the term Pear in the description field, then press the TAB key, some VBA code queries a SOAP Catalog Web Service to see if it can find a matching product, then it fills out the details... When you're done, you click the Send button and the RosettaNet PIP 3 A4 XML Purchase Order format is generated, and the order is sent..." With sample code. See also "UDDI: An XML Web Service." References: (1) UDDI; SOAP; (3) RosettaNet.

• [March 23, 2001] "Software Verification and Functional Testing with XML Documentation." By Ernest Friedman-Hill. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences (HICSS-34), edited by R. H. Sprague. Los Alamitos, CA, USA: IEEE Computer Society. Meeting: January 3-6, 2001. Maui, Hawaii. Abstract: "Continuous testing is an important aspect of achieving quality during rapid software development. By making the user documentation for a software product into part of its testing machinery, we can leverage each to benefit the other. The documentation itself can be automatically tested and kept in a state of synchronization with the software. Conversely, if the documentation can be machine interpreted, evaluation of the software's adherence to this description simultaneously verifies the documentation and serves as a functional test of the software. This paper presents an application of these ideas to a real project, the manual for Jess, the Java Expert System Shell. The Jess manual is rich in machine-interpretable information and is used in several distinct modes within Jess' extensive functional and unit test suites. The effort to maintain the accuracy and completeness of Jess's documentation has dropped significantly since this method was put in place." [Note: "Jess is a rule engine and scripting environment written entirely in Sun's Java language by Ernest Friedman-Hill at Sandia National Laboratories in Livermore, CA. Jess was originally inspired by the CLIPS expert system shell, but has grown into a complete, distinct Java-influenced environment of its own. Using Jess, you can build Java applets and applications that have the capacity to 'reason' using knowledge you supply in the form of declarative rules."] Details: "The Jess project is primarily a research project. While the basic syntax of the Jess language stays relatively constant, features are added and removed on a regular basis as requirements evolve and new ideas are tried out. Nevertheless, Jess is a small project, supported by one person working part-time. Taken together, the small project size, the dynamic nature of the software itself, and the large user base make the problem of maintaining up-to-date documentation for Jess particularly acute... It is also very easy to extend the Jess language with new commands written in Java or in Jess itself, and so the Jess language can be customized for specific applications. Jess is therefore used in a range of different ways, meaning that its documentation must cover many topics. The software is in use at hundreds of sites around the world in industries including e-commerce, insurance sales, telecommunications, and R&D, so the documentation must be of sufficient quality and completeness to satisfy the broad user base. If documentation were interpretable by computer, then the behaviour described in the documentation could be verified by the test machinery. Writing documentation would no longer be a 'superfluous' activity, but instead it would be an integral part of the development process. Inaccurate documentation becomes as serious as any other bug detected during testing. We have applied this technique to a real project, the ongoing development of Jess', the Java Expert System Shell, using XML as the documentation format. This paper describes this effort and suggests some potential enhancements for future work... The validation system described here proved itself to be very useful in the development process from Jess 4.0 to 5.1. The effort required to maintain good user documentation was greatly reduced. Approximately ten alpha and beta releases of Jess over the space of a year were made, and each shipped with a completely up-to-date manual. All of the examples in each of the manuals were correct; conversely, the software always performed as described in the manual. Many extensions to this scheme are possible. The possibility for expanded use of <functiondef> has already been implied. If the argument and return-value descriptions were machine readable, then a series of simple tests for every documented function could be automatically generated to verify that the types and number of arguments, and the type and sometimes identity of the return value, adhered to the documentation. Another possibility would be the confirmation of the existence and signature of Java API functions mentioned in the manual. A special tag is already used to format such references in the printed documentation. Again, it should be possible to automatically generate some very simple unit tests for such functions."

• [March 23, 2001] "Using XML/XMI for Tool Supported Evolution of UML Models." By F. Keienburg and Andreas Rausch (Institut für Informatik, Technische Universität München). In Proceedings of the 34th Annual Hawaii International Conference on System Sciences (HICSS-34). Edited by: R. H. Sprague. With 19 references. Los Alamitos, CA, USA: IEEE Computer Society, 2001. Meeting: January 3-6, 2001. Maui, Hawaii. Abstract: "Software components developed with modern tools and middleware infrastructures undergo considerable reprogramming before they become reusable. Tools and methodologies are needed to cope with the evolution of software components. We present some basic concepts and architectures to handle the impacts of the evolution of UML models. With the proposed concepts, an infrastructure to support model evolution, data schema migration, and data instance migration based on UML models can be realized. To describe the evolution path we use XML/XMI files." Details: "One needed important thing for delivering transparent model changes is a neutral model specification format. For reasons of currently becoming a respected standard and being adopted by a lot of UML Case Tools vendors, XMI is chosen in this architecture as a neutral exchange format between different Case Tools. In addition there is a explosion of tools for handling XML documents very comfortable. The XMI standard specifies with a Document Definition Type (DTD), how UML models are mapped into a XML file. Besides this functionality XMI also specifies how model changes can be easily mapped into an XML document. Therefore XMI is a very good solution for solving some of the requested requirements for UML model evolution... XMI specifies a possibility for transmitting metadata differences. The goal is to provide a mechanism for specifying the differences between documents in a way that the entire document does not need to be transmitted each time. This is especially important in a distributed and concurrent environment where changes have to be transmitted to other users or applications very quickly. This design does not specify an algorithm for computing the differences, just a form of transmitting them. Only occurring model changes are transmitted. In this way different instances of a model can be maintained and synchronized more easily and economically. The idea is to transmit only the changes made to the model together with the necessary information to be able to apply the necessary changes to the old model. With this information you have the possibility for model merging. This means you can combine difference information plus a common reference model to construct the appropriate new model. A important remark to this topic is that model changes are time sensitive. This means changes must be handled in the exact chronological order for achieving the wanted result... In this paper we have shown that modern middleware infrastructures for the development of distributed applications provide rich support for model based development and code generation. But there is almost no support in case of model evolution. We have introduced some concepts and architectures to realize a tool supporting model evolution and data migration and to integrate this tool in modern infrastructures. To specify the model evolution the developer should use an XMI based difference description. Based on this concepts we have already implemented a first prototype. This is a very primitive version but it is already integrated in our framework AutoMate. Based on this experience we have realized the new version of the tool called ShapeShifter. ShapeShifter is now a stand alone tool supporting model evolution and data migration on top of Versant's object-oriented database. With ShapeShifter you specify the model difference in XMI and the model and the database are automatically migrated. ShapeShifter is now used in a first industrial project. The next step will be a complete integration in a CASE tool. Currently one can export and import XMI model files from some CASE tools. But for a full integration of ShapeShifter we need more sophisticated tools to generate the XMI difference file from to XMI based model versions. Moreover we plan to integrate ShapeShifter into several Enterprise Java Beans Container." Paper also available in Postscript format. See "XML Metadata Interchange (XMI)." [cache]

• [March 23, 2001] "Tip: Using JDOM and XSLT. How to find the right input for your processor." By Brett McLaughlin (Enhydra strategist, Lutris Technologies). From IBM developerWorks. March 2001. ['In this tip, Brett McLaughlin tells how to avoid a common pitfall when working with XSLT and the JDOM API for XML developers working in Java. You'll learn how to take a JDOM document representation, transform it using the Apache Xalan processor, and obtain the resulting XML as another JDOM document. Transforming a document using XSLT is a common task, and JDOM makes the transformation go quite easily once you know how to avoid the missteps. The code demonstrates how to use JDOM with the new Apache Xalan 2 processor (for Java).' "Being one of the co-creators of JDOM, I simply couldn't pass up the chance to throw in a few JDOM tips in a series of XML tips and tricks. This tip provides the answer to one of the most common questions I get about JDOM: 'How do I use JDOM and XSLT together?' People aren't sure how to take a JDOM Document object and feed it into an XSLT processor. The confusion often arises because most XSLT processors take either DOM trees or SAX events as input streams. In other words, there is not one obvious way to provide a JDOM Document as input in all cases. So how do you interface JDOM with those processors? The key to solving this problem is understanding the input and output options. First determine the input formats that your XSLT processor accepts. As I mentioned above, you'll usually be able to feed a DOM tree or I/O stream into the processor. But which of those is the faster solution? You're going to have to do a little digging to answer that question. That's right, I'm not going to give you a specific answer, but a method for figuring it out..."

• [March 23, 2001] "xADL: Enabling Architecture-Centric Tool Integration With XML." By Rohit Khare, Michael Guntersdorfer, Nenad Medvidovic, Peyman Oreizy, and Richard N. Taylor. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences (HICSS-34), edited by R. H. Sprague. Los Alamitos, CA, USA: IEEE Computer Society. With 29 references. Meeting: January 3-6, 2001. Maui, Hawaii. Abstract: "In order to support architecture-centric tool integration within the ArchStudio 2.0 Integrated Development Environment (IDE), we adopted Extensible Markup Language (XML) to represent the shared architecture-in-progress. Since ArchStudio is an architectural style-based development environment that incorporates an extensive number of tools, including commercial off-the-shelf products, we developed a new, vendor-neutral, ADL-neutral interchange format called Extensible Architecture description Language (xADL), as well as a "vocabulary" specific to the C2 style (xC2). This paper outlines our vision for representing architectures as hypertext, the design rationale behind xADL and xC2, and summarizes our engineering experience with this strategy." Details: "A future Unified Modeling Language (UML) graphical editor could produce SVG documents which could be transparently annotated with xADL and xC2 descriptions of the components and connectors those boxes and lines represent. Second, the approach we have adopted in xADL can be easily extended to support multiple architecture description languages (ADLs), even within a single XML schema. Our extensive study of ADLs has indicated that most all mainstream ADLs agree on the existence of components, connectors, and their configurations. A small number of ADLs, including Rapide and Darwin, do not explicitly model connectors. However, even these ADLs support simple component interconnections; furthermore, Rapide employs specialized "connection components" to support more complex interactions. Additionally, all ADLs model component interfaces and do so in a relatively uniform fashion. Therefore, these shared aspects of ADLs would become part of the basic xADL schema. That basic schema could then be extended in a number of ways to represent the varying parts of architectural descriptions across ADLs, such as the manner in which ADLs model architectural semantics, support evolution (both at system design time and run time), constrain the architecture (and its evolution), and so forth. Thus, for example, an xADL schema could simultaneously describe architectures specified in C2SADEL and Wright. If a particular tool is interested in the static model of behavior, it would access C2SADEL's component invariants and pre-and postconditions; alternately, if the tool is interested in the system's dynamic semantics, it would access Wright's CSP-related items and ignore others. Another possibility that xADL affords us is the support for multiple configurations of the same set of components, where we access the part of the schema representing the specific configuration we are interested in, disregarding all other configurations... We adopted XML as a key technology for enabling architecture-centric tool integration in the ArchStudio 2.0 IDE. The C2 style eased the evolution from the previous version's custom text file format, C2SADEL, to a generic XML AST as the repository. This had immediate benefits for integrating several tools' data in the same file, for annotating existing data without interfering with its original use, and for hyperlinking to external data transparently. Furthermore, we developed a new ontology for describing entire families of Architecture Description Languages (ADLs). By extracting the five most common abstractions and their relations into a top-level xADL namespace, we were able to separately represent data specific to the C2 architectural style and C2SADEL in a subsidiary xC2 namespace. These technologies directly aided a strictly distributed team to integrate a substantial set of research and commercial tools within ArchStudio 2.0. Our eventual aim is even wider, to support Internet-scale development, with potentially large and varying developer communities composing systems over long times and distances. Representing architectures as hypertext affords us reach; extracting our ontology in XML promises depth, through integration with generic, non-ADL-aware XML applications." See also the xADL discussion and references. [cache]

• [March 23, 2001] "Structured Data Exchange Format (SDXF)." By M. Wildgrube. Network Working Group, Request for Comments 3072. March 2001. "This document specifies a data exchange format and, partially, an API that can be used for creating and parsing such a format. The IESG notes that the same problem space can be addressed using formats that the IETF normally uses including ASN.1 and XML. The document reader is strongly encouraged to carefully read section 13 before choosing SDXF over ASN.1 or XML. Further, when storing text in SDXF, the user is encourage to use the datatype for UTF-8, specified in section 2.5." Abstract: "This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent." Compare ASN.1: "The idea behind ASN.1 is: On every platform on which a given application is to develop descriptions of the used data structures are available in ASN.1 notation. Out off these notations the real language dependent definitions are generated with the help of an ASN.1-compiler. This compiler generates also transform functions for these data structures for to pack and unpack to and from the BER (or other) format. A direct comparison between ASN.1 and SDXF is somehow inappropriate: The data format of SDXF is related rather to BER (and relatives). The use of ASN.1 to define data structures is no contradiction to SDXF, but: SDXF does not require a complete data structure to build the message to send, nor a complete data structure will be generated out off the received message." SDXF vs. XML: "On the one hand SDXF and XML are similar as they can handle any recursive complex data stream. The main difference is the kind of data which are to be maintained: (1) XML works with pure text data (though it should be noted that the character representation is not standardized by XML). And: a XML document with all his tags is readable by human. Binary data as graphic is not included directly but may be referenced by an external link as in HTML... (2) SDXF maintains machine-readable data, it is not designed to be readable by human nor to edit SDXF data with a text editor (even more if compression and encryption is used). With the help of the SDXF functions you have a quick and easy access to every data element..." [cache]

• [March 23, 2001] Examplotron 0.1." By Eric van der Vlist (Dyomedea). "The purpose of examplotron is to use instance documents as a lightweight schema language -- eventually adding the information needed to guide a validator in the sample documents. 'Classical' XML validation languages such as DTDs, W3C XML Schema, Relax, Trex or Schematron rely on a modeling of either the structure (and eventually the datatypes) that a document must follow to be considered as valid or on the rules that needs to be checked. This modeling relies on specific XML serialization syntaxes that need to be understood before one can validate a document and is very different from the instance documents and the creation of a new XML vocabulary involves both creating a new syntax and mastering a syntax for the schema. Many tools (including popular XML editors) are able to generate various flavors of XML schemas from instance documents, but these schemas do not find enough information in the documents to be directly useable leaving the need for human tweaking and the need to fully understand the schema language. Examplotron may then be used either as a validation language by itself, or to improve the generation of schemas expressed using other XML schema languages by providing more information to the schema translators..." From the XML-DEV posting: "Beating Hook, Rick Jelliffe's single element schema language has been quite a challenge, but I am happy to announce examplotron a schema language without any element. Although examplotron does include an attribute, this attribute is optional and you can build quite a number of schemas without using it and I think it fair to say that examplotron is the most natural and easy to learn XML schema language defined up to know ;=) ... The idea beyond examplotron -and the reason why it's so simple to use- is to define schemas giving sample documents. Although examplotron can be used as a standalone tool, it can also be used to generate schemas for more classical -and powerful- languages and I don't think it will compete with them but rather complement them. Thanks for your comments..." See also: (1) the XML-DEV posting, and (2) "XML Schema Element and Attribute Validator." For schema description and references, see "XML Schemas."

• [March 22, 2001] "When less is more: a compact toolkit for parsing and manipulating XML. Designing a fast and small XML toolkit by applying object-oriented techniques." By Graham Glass (CEO/Chief architect, The Mind Electric). From IBM developerWorks. March 2001. ['This article describes the design and implementation of an intuitive, fast and compact (40K) Java toolkit for parsing and manipulating XML -- Electric XML -- the XML engine of the author's company. It shows one way to apply object-oriented techniques to the creation of an XML parser, and it provides useful insight into API design. The source code for the non-validating parser described in this article may be downloaded and used freely for most commercial uses.'] "XML is finding its way into almost every aspect of software development. For example, SOAP, the rapidly emerging standard that is likely to replace CORBA and DCOM as the network protocol of choice, uses XML to convey messages between Web services. When my company decided to create a high performance SOAP engine, we started by examining the existing XML parsers to see which would best suit our needs. To our surprise, we found that the commercially available XML parsers were too slow to allow SOAP to perform as a practical replacement for technologies like CORBA and RMI. For example, parsing the SOAP message in Listing 1 took one popular XML parser about 2.7 milliseconds... Our initial experiments indicated that we could build a small, fast, intuitive toolkit for parsing and manipulating XML documents that would allow our distributed-computing platform to approach the performance of existing traditional systems. We decided to complete the parser and make it available to the developer community, partly to earn some good karma, and partly to demonstrate that powerful toolkits do not need to be large or complex. I personally yearn for the days of Turbo Pascal when companies shipped full-blown development and runtime environments that took up just 30K! The main design decisions were: (1) Selecting a hierarchy for the object model that fitted naturally with the tree structure of an XML document; (2) Pushing the knowledge of how to parse, print, and react to removal into each 'smart' node; (3) Using a Name object to represent a namespace-qualified name; (4) Allowing get and remove operations to accept an XPath expression; (5) Using selection nodes to keep track of XPath result sets. The resulting parser achieves the goal of processing a SOAP message about as quickly as RPC over RMI. Table 1 shows a comparison of parsing the sample SOAP message in Listing 1 with the production release of Electric XML and with a popular DOM parser 10,000 times and calculating the average time to parse the document... [Popular DOM-based parser: 2.7 milliseconds; Electric XML: 0.54 milliseconds]. I hope that the article provides useful examples of object-oriented design in action, as well as an instance of the adage "less is more." I hope also that Electric XML might prove useful for your XML development efforts." The the source code for the Electric XML parser is available for download. Article also in PDF. [cache]

• [March 22, 2001] "XOIP: XML Object Interface Protocol." By Morten Kvistgaard Nielsen and Allan Bo Jørgensen. Centre for Object Technology, COT/3-34-V1.0. 116 pages. [Master's Thesis, Department of Computer Science, Aarhus University, 2001.] "XOIP describes a way in which heterogeneous networked embedded systems can interface to a variety of distributed object architectures using XML. An implementation of XOIP is available for download. This document is a thesis for the Masters Degree in Computer Science at the University of Aarhus... In this thesis we shall present our solution to the problem of achieving interoperability between heterogeneous distributed object architectures and paradigms. What makes our solution special is that it is specifically designed to address the problems faced by embedded systems, where lack of system resources have hitherto prevented their participation in distributed object systems. Since embedded systems are more likely to be placed in heterogeneous object systems than their desktop counterparts, the two issues are naturally linked." [cache]

• [March 22, 2001] "Gates Unveils Hailstorm." By Barbara Darrow. In Computer Reseller News (March 19, 2001). "Microsoft Chairman Bill Gates Monday unveiled Hailstorm, one more step in the company's attempt to transform itself into a provider of software-as-services. Hailstorm -- which the company positions as a set of user-centric services to ease e-commerce and Web applications--is not slated for production until 2002. These services theoretically will enable users with any Web-connected devices, including handheld machines and cell phones, to easily and securely access applications and information on the Net... Similar to Novell's DigitalMe service unveiled two years ago, Hailstorm will let a user log on once to the system, which would then remember critical information, including passwords to diverse Web sites and services. Other services will include calendar, address book, notification and authentication.CRN first broke the story of the Hailstorm platform, called by one source as Microsoft Passport on steroids, in January. Microsoft made a design preview of the service available Monday and brought a number of potential partners -- including eBay, Groove Networks and American Express--onstage for demonstrations. By integrating Hailstorm services with its own auction APIs, for example, eBay would enable its own users to get realtime notification when someone has overbid them on a planned purchase. Similarly, American Express Blue Card users trying to order an out-of-stock book would receive notification from the merchant when the title is back in stock, and then click on that message to initiate the transaction... Certain base-level functionality -- such as single log-in -- will continue to be offered for free, but users will be charged for value-added services and on usage, company executives say. Still, it remains to be seen whether Microsoft, whose relationships with partners have been problematic at times, will be the partner of choice here." See: "Microsoft Hailstorm."

• [March 22, 2001] "Interview: Tim Berners-Lee on the W3C's Semantic Web Activity." By Edd Dumbill. From XML.com. March 21, 2001. ['The World Wide Web Consortium has recently embarked on a program of development on the Semantic Web. This interview outlines the vision behind the new Activity, and how it relates to XML in general.'] "Tim Berners-Lee: The W3C operates at the cutting edge, where relatively new results of research become the foundations for products. Therefore, when it comes to interoperability these results need to become standards faster than in other areas. The W3C made the decision to take the lead -- and leading-edge -- in web architecture development. We've had the Semantic Web roadmap for a long time. As the bottom layer becomes stronger, there's at the same time a large amount falling in from above. Projects from the areas of knowledge representation and ontologies are coming together. The time feels right for W3C to be the place where the lower levels meet with the higher levels: the research results meeting with the industrial needs... We always design the Activity to suit the needs of the community at the time. Examples of infrastructural work in which we did this are the HTTP, URI, and XML Signature work. We wanted the attention of the community experts, and things required wide review. More of our Activities and working groups are moving toward a more public model; XML Protocol is a perfect example. SW needs to be really open, as many resources for its growth are from the academic world. We need people who may at some point want to give the group the benefit of their experience, without having a permanent relationship with the consortium. It's not particularly novel. It's combining the RDF Interest Group with W3C internal development stuff. We need to find what the Knowledge Representation community have got that's ripe for standardization, and what it hasn't and so on. Coordination will be very important." See: "XML and 'The Semantic Web'."

• [March 22, 2001] "Tutorial: An Introduction to Scalable Vector Graphics." By J. David Eisenberg. From XML.com. March 21, 2001. ['This introduction to SVG teaches you all you need to know about the W3C's vector graphics format in order to start putting it to use in your own web applications.'] "If you're a web designer who's worked with graphics, you may have heard of Scalable Vector Graphics (SVG). You may even have downloaded a plug-in to view SVG files in your browser. The first and most important thing to know about SVG is that it isn't a proprietary format. On the contrary, it's an XML language that describes two-dimensional graphics. SVG is an open standard, proposed by the W3C... This article gives you all the basic information you need to start putting SVG to use. You'll learn enough to be able to make a handbill for a digital camera that's on sale at the fictitious MegaMart..." [From the W3C SVG Web site: " SVG is a language for describing two-dimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. Text can be in any XML namespace suitable to the appplication, which enhances searchability and accessibility of the SVG graphics. The feature set includes nested transformations, clipping paths, alpha masks, filter effects, template objects and extensibility. SVG drawings can be dynamic and interactive. The Document Object Model (DOM) for SVG, which includes the full XML DOM, allows for straightforward and efficient vector graphics animation via scripting. A rich set of event handlers such as onmouseover and onclick can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on SVG elements and other XML elements from different namespaces simultaneously within the same Web page."] See: "W3C Scalable Vector Graphics (SVG)."

• [March 22, 2001] "Perl & XML: Using XML::Twig." By Kip Hampton. From XML.com. March 21, 2001. ['XML::Twig provides a fast, memory-efficient way to handle large XML documents, which is useful when the needs of your application make using the SAX interface overly complex.'] "If you've been working with XML for a while it's often tempting frame solutions to new problems in the context of the tools you've used successfully in the past. In other words, if you are most familiar with the DOM interface, you're likely to approach new challenges from a more-or-less DOMish perspective. While there's plenty to be said for doing what you know will work, experience shows that there is no one right way to process XML. With this in mind, Michel Rodriguez's XML::Twig embodies Perl's penchant for borrowing the best features of the tools that have come before. XML::Twig combines the efficiency and small footprint of SAX processing with the power of XPath's node selection syntax, and it adds a few clever tricks of its own..."

• [March 22, 2001] "Overcoming Objections to XML-based Authoring Systems." By Brian Buehling. From XML.com. March 21, 2001. ['When deploying an XML-based content management system, common misconceptions must be corrected. This article helps IT professionals do just that.'] "During a recent development effort, one of our clients was alarmed at the conversion costs of the proposed XML-based content management system compared to the existing MS Word-based process. This was just one instance of an alarming trend of balking at XML-based systems in favor of using public web folders, indexed by some full-text search engine, as part of a local intranet. In the short run, these edit, drop, and index solutions have some appealing features, including low development and conversion costs. But they are short-lived systems that either wither from lack of functionality or rapidly outgrow their design. Fortunately, the initial objections to the cost of building an XML-based content repository have become fairly predictable. In most cases they are based on misconceptions about XML or on an overly optimistic view of alternative approaches. Even though implementing an XML-based content management system is not always the best approach for an organization, any architectural decision should be made only after thoroughly overcoming the common misconceptions of the technology involved. The list of questions below is intended to be a guide for IT professionals to discuss intelligently the pros and cons of developing an XML document repository..."

• [March 22, 2001] "Building User-Centric Experiences. An Introduction to Microsoft HailStorm." A Microsoft White Paper. Published: March 2001. "... For users, HailStorm will be accessed through their applications, devices and services (also known as 'HailStorm end-points'). A HailStorm-enabled device or application will, with your consent, connect to the appropriate HailStorm services automatically. Because the myriad of applications and devices in your life will be connected to a common set of information that you control, you'll be able to securely share information between those different technologies, as well as with other people and services. Developers will build applications and services that take advantage of HailStorm to provide you with the best possible experience. The HailStorm platform uses an open access model, which means it can be used with any device, application or services, regardless of the underlying platform, operating system, object model, programming language or network provider. All HailStorm services are XML Web services, which are based on the open industry standards of XML and SOAP; no Microsoft runtime or tool is required to call them. Naturally, the .NET infrastructure provided by Visual Studio.NET, the .NET Framework, and the .NET Enterprise Servers will fully incorporate support for HailStorm to make it as simple as possible for developers to use HailStorm services in their applications. From a technical perspective, HailStorm is based on Microsoft Passport as the basic user credential. The HailStorm architecture defines identity, security, and data models that are common to all HailStorm services and ensure consistency of development and operation. HailStorm is a highly distributed system and can help orchestrate a wide variety of applications, devices and services. The core HailStorm services use this architecture to manage such basic elements of a user's digital experience as a calendar, location, and profile information. Any solution using HailStorm can take advantage of these elements, saving the user from having to re-enter and redundantly store this information and saving every developer from having to create a unique system for these basic capabilities. HailStorm is expressed and accessed as a set of industry standard XML Web services. HailStorm-enabled solutions interact with specific HailStorm facilities via XML message interfaces (XMIs), which are simply a set of XML SOAP messages. The initial set of HailStorm services will include: myAddress: electronic and geographic address for an identity; myProfile: name, nickname, special dates, picture; myContacts: electronic relationships/address book; myLocation: electronic and geographical location and rendez-vous; myNotifications: notification subscription, management and routing; myInbox: inbox items like e-mail and voice mail, including existing mail systems; myCalendar: time and task management; myDocuments: raw document storage; myApplicationSettings: application settings; myFavoriteWebSites: favorite URLs and other Web identifiers; myWallet: receipts, payment instruments, coupons and other transaction records; myDevices: device settings, capabilities; myServices: services provided for an identity; myUsage: usage report for above services. The HailStorm architecture is designed for consistency across services and seamless extensibility. It provides common identity, messaging, naming, navigation, security, role mapping, data modeling, metering, and error handling across all HailStorm services. HailStorm looks and feels like a dynamic, partitioned, schematized XML store. It is accessed via XML message interfaces (XMIs), where service interfaces are exposed as standard SOAP messages, arguments and return values are XML, and all services support HTTP Post as message transfer protocol..." See: "Hailstorm."

• [March 22, 2001] [Transcript of] Remarks by Bill Gates. HailStorm Announcement. Redmond, Washington, March 19, 2001. "...schema is the technical term you're going to be hearing again and again in this XML world. It's through schemas that information can be exchanged, things like schemas for your appointments, schemas for your health records. The work we're announcing today is a rather large schema that relates to things of interest to an individual. And you'll recognize very quickly what those things are, things like your files, your schedule, your preferences, all are expressed in a standard form. And so, by having that standard form, different applications can fill in the information and benefit from reading out that information and benefit from reading out that information. And so it's about getting rid of these different islands. It's really a necessary step in this revolution that there be services like HailStorm. There's no way to achieve what users expect and really get into that multiple device, information any time, anywhere world without this advance. So you can envision the XML platform as having two pieces. The foundation pieces that are done in the standards committee, going back to that original XML work in 1996, but now complemented by a wide range of things, things like X-TOP, X-LINK, the schema standards that have come along. One of the really key standards is this thing called SOAP, that's the way that applications that were not designed together can communicate and share information across the Internet. You can think of it as a remote procedure call that works in that message-based, loosely coupled environment. Now, the XML movement has gained incredible momentum. I'd say the last year has really been phenomenal in terms of the momentum that this has developed. Part of that is we also have other large companies in the industry, besides Microsoft, really join into this. So if you look at two of the recent standards, SOAP and UDDI, we had many partners, including IBM, that were involved in a very deep way, helping to design that standard, and really standing up and saying that was critical to their whole strategy. And so you're seeing a real shift towards these XML Web services, a real shift away from people saying it's one computer language, or it's just about one kind of app server, to an approach now that is far more flexible around XML. The kind of dreams that people have had about interoperability in this industry will finally be fulfilled by the XML revolution. And so, although we're focusing on HailStorm today, it's important to understand that this XML approach allows data of all types, business application data, to move easily between different platforms, between different companies in a very simple way..." See: "Hailstorm." [cache]

• [March 22, 2001] "Exclusive DevX Q&A with the HailStorm Team." From DevX. March 22, 2001. ['On March 19, and in a private design preview four days earlier, Microsoft unveiled what Bill Gates called "probably the most important .NET building block service." Codenamed HailStorm, this suite of user-centric XML Web services turns things inside out, said its architect and distinguished engineer Mark Lucovsky. "Instead of having an application be your gateway to the data, in HailStorm, the user is the gateway to the data." After the press conference, XML Magazine Editor-in-Chief Steve Gillmor sat down with Lucovsky and Microsoft director of business development Charles Fitzgerald to discuss what Gates calls the beginning of the XML revolution.'] "Gillmor: Can you give us an XML-focused view of HailStorm? Lucovsky: The key thing is that we take the individual and hang a bunch of services off that individual -- and those services are exposed as an XML document. Off of an ID or a person, we hang a calendar -- and the calendar has an XML schema and a set of access mechanisms to manipulate that XML data. We take our whole service space and wrap that around this identity-based navigation system, and expose those services as XML that you can process using any tool set that you like. If you do a query, you can specify your query string as either an XPath expression or an XQL query string. It will give you back a document fragment. Once it's in your control, you can process it with your own DOM or SAX parser -- whatever makes sense for the application. You can use an XSL transform and throw away half of what we gave back because you only cared about this element or that attribute; it's up to the application. The four basic verbs that we support are 'Add,' 'Query,' 'Update,' 'Delete' -- they all relate back to XPointer roots. We're not inventing any kind of new navigation model; we're just utilizing existing XML standards. There are additional domain-specific methods on some of the services. But the fundamental primitive is that you think of the service as if it were an XML document, and that document has a schema that includes types that are specific to that document. Gillmor: Where's the document stored? Lucovsky: The system is set up so that each service instance has its own address. It's very distributed -- or it can be. My 'MyAddress' service and your 'MyAddress' service can be at two different data centers on two different front-end clusters anywhere. That's all done dynamically -- we can partition with the granularity of 'an individual service instance can be located anywhere on the network' -- and we look up that address as part of the SOAP protocol to talk to it. The actual data for a given service, if it's a persistent service -- like 'MyAddress' or something like that -- is then shredded from its XML form into a relational database using our shredding technology. We map the XML into element IDs and attribute IDs, smash it into a database, query it out using our database tables, and then reconstitute the XML. It's like -- it is an XML database; that's how you do an XML database. We're not taking a blob and storing it and going crazy like that... In HailStorm, you're talking XML natively -- so that whole section disappears. Our type model is XML; our type model is XSD schema. Our type model isn't an object hierarchy that we then have to figure out how to factor into XML. And the bulk of the work in SOAP moving forward -- there's a lot of efforts in SOAP -- but one piece of work in SOAP is beefing up that section of the spec. Other activities in SOAP are working on routing headers and other headers that you would carry in that SOAP-header element. We're embracing all of SOAP, but there's not a lot there that's directly relevant to us in the serialization... Are we using XML signatures? We're working on that to see if it can do what we need it to do with respect to the body element. We think we can. Are we're using Kerberos wrapped in XML? Yes. The SOAP processor -- that's a meaningless thing -- e