This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- Update: Accessible Rich Internet Applications (WAI-ARIA) Version 1.0
- Generating Generic XForms for OpenOffice
- Battlefield Knowledge Management
- Should we Allow XML Namespace Names to be IRIs Rather Than URIs?
- Silverlight: Create Animations with XAML and Expression Blend
- XML: The Good, the Bad and the Bloated
- Web Services for Peripherals and Point of Service (POS) Applications
Update: Accessible Rich Internet Applications (WAI-ARIA) Version 1.0
Michael Cooper, Rich Schwerdtfeger, Lisa Seeman, Lisa Pappas (eds), W3C Technical Report
See also: details of the call for comment
Generating Generic XForms for OpenOffice
Bryan Rasmussen, DevX.com
You can generate XForms in OpenOffice from sample input — as long as you're aware of the technique's limitations. A previous article on XForms in OpenOffice showed how to create a simple XForm in OpenOffice. The introduction to this particular technology came while working on the Danish UBL project, which needed a cross-platform implementation for some of the twenty-three (23) UBL 2.0 document types intended for use by small businesses. The project initially supported only three types: Invoice, CreditNote, and Order, but had a stated goal of supporting all the UBL formats. Unfortunately, it proved impossible to create this solution purely in XForms in OpenOffice. The project required supporting documents containing all possible elements, but the UBL Order implementation ran into performance problems, because, as described in the previous article, it keeps every binding in memory; therefore, a large number of bindings slows down the implementation measurably. Obviously, the complexity of expressions can also affect this. In my experience, forms that exceed several hundred bindings are unusable. A 10-line UBL Order was likely to have 500 or more bindings, and thus was not usable in an OpenOffice XForm. Nonetheless, the route to discovering this depressing information did produce some useful tools and techniques for others who want to work with smaller XML documents in OpenOffice. Because OpenOffice's internal representation is ODF XML, it is natural to generate ODF from other XML formats using an XSLT transformation. This applies equally well to an XForm inside of an ODF document. You always need to take a few things into account when making an XSLT transform, such as the processor and the context (web server, command line application, etc.). OpenOffice adds yet another consideration: You have the possibility of running the transformation as an XSLT Filter. An XSLT Filter combines an XSLT stylesheet and some OpenOffice settings registered in OpenOffice that allows OpenOffice to open various XML-based formats and work with them in the context of the application. This article explains how to create an OpenOffice XSLT Filter that applies generically to all example XML instances—in other words, it's as a basic tool for working with XML in OpenOffice XForms. We demonstrate a method to generically transform XML input formats to generate XForms that will run in OpenOffice so users can edit the XML input values. The XSLT used in the article is sufficiently configurable that you can maintain, extend, and reuse it relatively easily without breaking functionality.
See also: XML and Forms
Battlefield Knowledge Management
Dan Campbell, Government Computer News
We are all familiar with the frustration of a fruitless Internet search, where querying a seemingly simple topic returns a laundry list of enormous documents that must be downloaded just to find one piece of information. Now picture the frustration of executing such a search not over a broadband link in your home or office, but instead over a slow speed link as a solider deployed in a hostile forward area, under pressure and time constraints to gather critical information in preparation for battle. The Army may have found a solution by implementing a Battle Command Knowledge System (BCKS) to improve soldiers' abilities to search the Army's Warrior Knowledge Base (WKB). The system is based on MarkLogic Server, an XML-based content platform designed to allow for granular database searches, efficient document delivery, and knowledge and information sharing. The system enables soldiers to find the most up-to-date and cutting edge information that may assist them in the field. Enrique Alonso, director of federal consulting for MarkLogic: "Enemies are very dynamic, changing tactics all the time; there is a real need to share information among the troops in a fast and efficient way." The main feature of WKB is its ability to perform fast, specific searches. Rather than returning search results as a laundry list of links to large documents that would have to be downloaded and perused, BCKS returns very granular answers to queries generated by soldiers. The system is populated by Army content managers, who mine Army resources for applicable knowledge to add to the WKB repository. The content managers assign specific attributes (metadata) that characterizes the content and serves as keywords in the searches. The metadata parameters follow the Defense Department's Discovery Metadata Specification, a directive from the Pentagon intended to promote net-centric information sharing and reduce silos of information. Metadata may include specific items such as the originating command or a particular author of the content. Users of the system may also upload information to the database. A critical part of the system is the page-level, document-view concept, in which only the specific page of interest within a document is downloaded in order of relevance...
Should we Allow XML Namespace Names to be IRIs Rather Than URIs?
John Cowan, W3C Discussion List Posting
On behalf of the W3C XML Core Working Group, John Cowan delivered a communication to the W3C XML Internationalization Core WG and Internationalization Interest Group (IG) on the question of using IRIs for XML namespace names. Comment from other interested parties is welcome. Cowan: "As you probably know, XML Core is backporting the extended set of name characters from XML 1.1 to the 5th edition of XML 1.0, thus making them available to XML 1.0 users. The other features of XML 1.1 are not being backported at this time. However, we are considering backporting features of XML Namespaces 1.1 (which is used exclusively with XML 1.1 documents) to XML Namespaces 1.0 (which is used exclusively with XML 1.0 documents). The relevant feature is allowing XML namespace names to be IRIs rather than URIs. Point in favor: allowing an IRI permits the namespace name (which is used only for naming, not for retrieval) to be at least partly meaningful in languages other than English. Point against: supporting full Unicode allows both visual spoofing and composed-vs.-decomposed character spoofing of namespace names, possibly causing a document which appears to be in one namespace to be validated against the schema for another namespace. Namespace names are compared using codepoint-by-codepoint equality only, and this will not be changed. What do you think? Should we allow IRIs?" Addison Phillips (aka "Internationalization is not a feature. It is an architecture.") noted initially: "I would point out that Section 126.96.36.199 of IRI does address normalization, at least to some degree. Requiring NFC in namespace IRIs would address the composed-v-decomposed and combining-mark-reordering attacks (it would not address all visual spoof attacks—nothing can completely insulate a system from such an attack, however, even in ASCII). I know that 188.8.131.52 does not require NFC (in fact, it requires that late normalization to NFC *not* be done during IRI comparison). However, namespaces could define non-normalized IRIs as illegal. That said, I think using IRIs for namespaces makes a lot of sense—especially if we allow elements, attributes, and so forth to use the full range of Unicode. And since XLink and other specs use (LE)IRI, it would make some sense to port it... If one has gone to the trouble of assembling a DTD that uses (let's say) Tifinagh, it doesn't make much sense to require the namespace for that DTD to use a different script or more restrictive range of characters to reference it..."
See also: XML Namespace resources
Silverlight: Create Animations with XAML and Expression Blend
Lawrence Moroney, MSDN magazine
In this article the author discusses how transformations and animations are defined in Silverlight XAML (Extensible Application Markup Language). He introduces you to different types of transformation used to rotate, scale, or skew an object, as well as to freeform transformations using an affine matrix as applied to a shape. He then offers an overview of animations and showed you how to define an animation to run based on an XAML trigger. You see how animations change property values over time, and you look at the XAML types that support animating double, point, and color values. He then explains how to use key frames for finer control over your animations. Finally, he demonstrates the Expression Blend animation designer so you could see how easily animations can be generated visually using Expression Blend... One of the neat things about XAML is that you can not only declare your objects using an XML syntax, but that you can define transformations to apply to these objects in the same way. You don't need to be a programmer to rotate, move, and skew your objects. Also, XAML can be used to describe how you can animate your object, with an animation being defined as changing properties on the object over time... In the field of graphics, a transform defines how to map points from one coordinate space to another. This is typically described using a transformation matrix, a special mathematical construct that allows for simple mathematical conversion from one system to another. Silverlight XAML abstracts this matrix and supports four set transformations for rotation, scaling, skewing,and translation (movement). Silverlight XAML also has an additional special transformation type that allows you to define and implement your own matrix, which you can then use to combine transformations. Transformations are applied using transform properties. There are several different types of transform properties, which are applied to different object types.
See also: Silverlight documentation
XML: The Good, the Bad and the Bloated
Shawn P. McCarthy, Government Computer News
"Depending on whom you talk to, Extensible Markup Language (XML) is either the centralized solution for managing cross-platform and cross-agency data sharing, or it's a bloated monster that's slowly taking over data storage and forcing too much data through networks during queries.. The idea of markup languages originated in the publishing industry. Editors used to scribble notes and symbols on sheets of text. Those markups were shorthand messages to typesetters indicating that some text should be set as headlines, others as body text and certain words in bold, italic, etc. As the world migrated to electronic documents, a need arose to make those markups machine-readable. In the mid-1970s, the Standard Generalized Markup Language evolved as a way to embed markup messages into lines of text. Soon the streamlined Hypertext Markup Language (SGML) emerged as the Web evolved... [However] An XML file separates data content from the presentation layer of a Web page or any other application that needs to import the file. An XML file contains metadata about itself, categorizes various components of the file, and labels various data elements within the file using opening and closing tags..Although HTML is limited to a couple dozen sets of tags, XML can be extended as needed, as long as those who need to exchange data agree on the schema. An XML schema is a set of data tags and rules about how those tags should be used to identify types of data within a document or data collection. Once a schema is finalized, it can be used to identify and share information in a specific way... Government data managers have developed several government-specific XML schemas to enable data sharing among multiple systems. Total system compatibility might not be necessary if two systems are at least able to import and export XML files and provide a directory that indicates where the files are kept and what data they contain. But XML bloat occurs when files are poorly constructed or not equipped for the jobs they must perform. There is a strong temptation to cram too much information into files, which makes them larger than they need to be. When an agency needs only part of the data, if often has to accept the whole file, including long blocks of text. And when an agency needs to support more than one XML schema, it can end up with redundant data that must be exported in more than one set of files... Technologies are evolving that can help with XML bloat. First is the evolution of platform-based XML solutions that offer a single system to author, tag, store and manage XML files. They also allow developers to set the policies for dynamic XML integration into other documents or applications. Mark Logic is one of the best-known purveyors of such solutions, though other companies, such as TigerLogic Corp., are making headway. Second is the idea of XML file-size reduction..." [Note: Efficient XML Interchange (EXI) Format 1.0 is one solution for "compact representation for the Extensible Markup Language (XML) Information Set".]
Web Services for Peripherals and Point of Service (POS) Applications
V. Srikanth, J. Koester, T. Grigsby; IBM developerWorks
This Part 1 article demonstrates how an emerging standard, Web Services for Point of Service (WS-POS) peripherals, allows interoperability between retail peripheral devices (printers, scanners) and point-of-service (POS) applications, irrespective of the platform (Java or Microsoft .NET) to which they are physically connected. All the major Web services players support the Web services stack that's used to build the WS-POS open standard. This means that peripherals aren't required to adhere to a single platform, but can instead behave as true services. WS-POS is a new standard in development at the Association for Retail Technology Standards (ARTS), which addresses the future requirement of sharing peripheral devices, such as printers and scanners, between multiple POS terminals in a retail store. Peripheral sharing makes new retail scenarios possible, which can transform the customer experience. In the world of retail IT, new and innovative solutions bring many devices and peripherals into the store. In the past, the in-store technology focus for retailers included the traditional front-end point of sale (that is, cash register), associated receipt printers, scanners, and displays. However, the current retail environment includes traditional technology and new POS devices, such as cart-mounted tablets, store associate PDAs, self checkout, and kiosks, to name a few. Outfitting every POS solution in store with a scanner, printer, display, magnetic stripe reader (MSR), and payment device would be too expensive. That's why peripheral sharing in the store is imperative—to provide these new employee and customer touch points and drive accessibility to peripherals regardless of the user's location or the device used in a store. WS-POS offers an open standards-based methodology for enabling these solutions. [Note: In January 2008, ARTS announced the release of the 'UnifiedPOS Release 1.12' specification, with an XML mapping. IBM's Albert Wong reported in a July 22, 2008 blog ("Pragmatic Viewpoints of Open Computing") that August 2008 meetings of the ARTS XML and Data Model Committee will include WS-POS technical work: "Coordinating ARTS XML and UnifiedPOS web services efforts UnifiedPOS has created XML-POS as the foundation of WS-POS that will permit remote device connectivity as a web service. To complete WS-POS, UnifiedPOS needs to integrate the SOA Best Practices and Blueprint developed by ARTS XML. Cooperation with The Open Applications Group (OAGi). OAGi is the very successful developer of horizontal XML schemas and messages used across many industries. ARTS members using OAGi standards are requesting guidelines for how ARTS vertical standards can intersect with OAGi."]
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.||http://sun.com|
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/