UBL: Another Opportunity for FOSS in the Enterprise
E-business still lacks a universal, cheap and easy-to-implement standard language. At least, this was the case until a few months ago. Today, the Universal Business Language (UBL) is ready to fill this gap, and it looks to be solid offering rather than yet another bunch of buzzwords. UBL comes from OASIS), the same folks who standardized the OpenDocument format for office files, and UBL is equally as open. Participation in the OASIS UBL Technical Committee is open to all organizations and individuals. OASIS hosts an open mailing list for public comment, as well as the ubl-dev mailing list for exchanging information on implementing the standard. UBL is provided on a royalty-free basis and is available to all, without licensing or other fees.
UBL starts with three basic premises. First, XML is a wonderful technology, but in and of itself, it is no guarantee of standards. Second, no company works in isolation or has contacts only inside its industry segment. Therefore, if every company had its own XML-based system, nobody would accomplish anything. Good business requires efficient, cross-industry communication. Third, forget about reinventing the wheel or substituting it with some vague, untested idea. UBL is all about doing tomorrow the same things we are doing today but in a faster and less error prone way.
The basic goal behind UBL is simply to define a single, XML-based format for all the usual commercial documents--invoices, purchase orders and so on. Using this format, an American buyer could create and e-mail in English an order for, say, one hundred carpets. The Thai employee who receives the order in her in-box could open the file with any UBL-enabled application and read it in her native language; the document already would be formatted according to local policies and business regulations. In addition to this, she simply could drag-and-drop the order to the company inventory system without typing anything, without wasting time and without risking errors.
UBL also can be used as the business data format in a variety of Web services. Although solutions to this problem have existed for years, before UBL, such solutions were cost effective for only large corporations with millions of transactions to process each year.
To know more about this UBL standard and how FOSS programmers may add support for it in office applications, starting with OpenOffice.org, we talked to Jon Bosak, chairman of the UBL Technical Committee, and Lars Oppermann, software engineer for the framework and XML projects in StarOffice/OpenOffice.org.
Linux Journal: Let's start by looking at how to add UBL support to some software applications. Which specifications should a developer read? Are APIs and libraries already available; if so, under which license? Would they be constrained, at least today, to only a few software languages?
Jon Bosak: Everything currently available for users and developers is included as part of the UBL 1.0 specification. Because UBL 1.0 was released recently as a standard, no APIs or software libraries are available for it yet. But, I expect to see those appear as soon as software developers begin to wake up to the huge business opportunity presented by UBL. I often compare UBL to HTML. Both are specific XML tagging languages created to enable interoperability in specific domains, which for HTML was hypertext publishing and for UBL is business-to-business electronic commerce. UBL is at about the same place on the adoption curve that HTML was in 1992. So there is not much support available yet, but we can expect that to change very quickly as people start to understand the advantages of a standard approach to business data interchange.
LJ: How can UBL documents be integrated in current office environments? Is it already possible to use this standard in production with OpenOffice.org, Microsoft Office or any other application, from corporate-level products to SOHO ones?
JB: The key here is the creation of plug-ins that will enable office software packages to translate their internal data formats to the standard UBL form for output and to perform the reverse translation for input. Early prototypes have demonstrated the viability of this approach. Now it's up to the producers of these office systems to provide the necessary translation capabilities.
LJ: Let's hope that free software products will be the among the first to provide UBL support. It might be exactly what is needed to make more businesses switch to FOSS to reduce costs.
Is UBL only for business-to-business use, or is it also usable/needed by private citizens?
JB: UBL defines standard forms for basic business messages, such as purchase orders, shipping notices and invoices. It is not intended for non-business use. However, some pieces of the UBL standard, such as the UBL naming and design rules for XML schemas and the UBL specification for code lists, are being adopted for other XML standardization initiatives. So, it's quite possible that future XML standards usable by private citizens may be based in part on these aspects of the UBL work.
LJ: Let's discuss with Lars the technical details of the problem. Can UBL 1.x documents already be read or written with OpenOffice.org?
Lars Oppermann: OpenOffice.org is aiming to support UBL through its general XML integration efforts. The software can read or write any XML-based format, including UBL instances, by means of its XSLT import and export filter. We have worked on a UBL import of XSLT transformation and used it for demonstration purposes within the OASIS UBL committee. In the future, full UBL instance editing and creation capabilities will be provided through OpenOffice.org's XForms support. This approach has shown promising results and already was demonstrated at XML2004.
LJ: Who is working on this?
LO: The UBL Technical Committee at OASIS has formed a human interface sub-committee (HISC) that is looking at ways to edit UBL. This committee also looked at XForms and OpenOffice.org XForms.
JB: Lately the HISC has made considerable progress in defining input specifications for UBL documents. These specifications are not XForms but can be applied using XForms. Micah Dubinko, a leading XForms expert, has done a lot of work on the spec over the last few months. To have an idea of what is happening, check out this wiki.
LJ: What would be the best way to start an UBL/OO.o related project?
LO: Getting in touch with the OASIS UBL folks or with the community at xml.openoffice.org would be the best course of action. Because the UBL Technical Committee itself is not so much interested in particular implementations but rather in general approaches, OpenOffice.org might be the best place.
LJ: What about cross-language support? Imagine an English company sending a purchase order to a French company. The promise of UBL is it should make it possible for the French user's software to parse UBL and show on-screen a French version of the same document. What would OO.o need to do this? More coding--how much, at which level and why?--or simply the right libraries, templates and so on?
LO: Everybody would need a localized version of the XForms document that displays the actual instance. Data in the instance mostly isn't locale dependent. If localized data is contained in the instance, XForms could provide means for filtering out the correct values.
JB: The UBL 1.0 International Data Dictionary (IDD) provides an important resource for developers creating localized UBL software. An IDD draft for Chinese, Japanese, Korean and Spanish is undergoing balloting as an OASIS Committee Draft and should be available for public review [sometime in April]. A preliminary version (Excel, sorry) of the IDD is already available here. In that document, the columns labeled "business terms" are intended specifically for use in populating localized drop-down menus and field labels in forms. As with all the UBL 1.0 spreadsheets, the IDD will be provided in both OpenOffice.org and Excel formats when the Committee Draft is published.
LJ: Any other general comments or pointers for developers?
LO: No actual coding is needed in OpenOffice.org to support UBL. You only have to create XForms documents that work on top of the UBL documents. Also, check out the W3C XForms pages and the OpenOffice.org XForms specs. General XML information on OpenOffice is available here.
LJ: Thanks to Jon and Lars for their time.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide