XML News Desk
UBL "might help .NET" says XML founder
UBL "might help .NET" says XML founder
By: XML News Desk
Jan. 1, 2000 12:00 AM
(January 22, 2002) – If anyone ever forgets that XML is not a language but a metalanguage, or thinks that it's new (it’s not – it builds on 30 years of research and 14 years of SGML standardization), or doesn't realize that all XML languages can be processed by a single lightweight parser, or fails to see that its lack of limits on namespace or structural depth makes it powerful for data modeling...then Jon Bosak is definitely the man to set them straight.
Officially titled Distinguished Engineer, the highly articulate Bosak has been Sun Microsystems’s point man involved with XML ever since a cross-industry group, organized and led by Sun, first drafted it as a simplified subset of SGML capable of supporting the definition of an unlimited number of special-purpose languages optimized for different specific industries and domains.
The rest, as they say, is history.
XML-J Industry Newsletter invited the team-spirited metalinguist to bring SYS-CON Media's audience up to speed on the latest far-reaching e-commerce initiative he’s spearheading, namely the Universal Business Language (UBL). Here we bring you the exclusive interview in full:
XML-J: The inaugural meeting of the OASIS technical committee devoted to UBL was held last November in Menlo Park, California, and hosted by Sun. How would you briefly summarize Sun's specific interest in UBL?
BOSAK: At this point Sun's interest is just what it was when we organized and led the creation of XML -- to do the right thing for the industry. Later on I hope we can leverage that leadership into products.
XML-J: Who are some of the other leading industry players involved?
BOSAK: That's a tricky question to answer because of the way OASIS technical committees are set up. The members of OASIS TCs are individual experts -- they don't formally represent the companies they work for. So you have to be careful about attributing company sponsorship just because an employee is participating. On the other hand, subsidizing the work of a technical expert is a pretty big deal in this economy, so company affiliation isn't meaningless, either.
Based on the resources they've committed to the work, the biggest corporate UBL supporters at this point are Sun, SAP, and Commerce One. At the first meeting, we also got people from Boeing, VerticalNet, KPMG, GE, Contivo, Schemantix, the U.S. Navy, Oracle, HP, the U.S. Government Services Administration, Sterling Commerce, Pointgain, SoftQuad, AccessVia, LMI, and CSW Informatics. And we've got about a dozen other people from consultancies you don't ordinarily hear about. This is actually a good thing, because it means we're getting the really knowledgeable people that the big companies will be looking to for advice a year from now.
We've also got formal liaisons from some key industry groups -- EIDX for the electronics industry, ARTS for retail, XBRL for accounting, and RosettaNet for information technology. I expect quite a few more of these vertical industry organizations to establish relationships with UBL as they start to realize that we're solving some basic information exchange problems that are common to all of them. And we're working on getting liaisons from the main EDI standards bodies, though that takes a while.
XML-J: Were you all worried by the sheer proliferation of markup languages?
BOSAK: Well, the whole point of XML is to allow the creation of an unlimited number of special-purpose markup languages optimized for different domains. And in fact, the OASIS process is set up the way it is in order to allow an unlimited number of special-purpose XML languages to be standardized in parallel. There are some features of the process that make sense only in that context. So in itself, the proliferation of markup languages isn't a bug, it's a feature. It's basic to the whole XML concept.
What isn't basic to the XML concept is that you would have a heap of redundant markup languages for doing exactly the same thing. That's not helpful at all. Once you've identified a particular problem space, you want to assemble the people who know about that space and define one common markup language to deal with that space. Without a general agreement on one way of expressing something, you can't really communicate. That's what language is all about -- it's a general agreement about how to express things.
This is not to say that you're always going to see just one markup language come out of every problem space. Different people have different ideas about how to solve these problems. But you should be able to expect that over the course of time these different approaches will start to converge. That's what I think we're seeing with UBL. We've got about half a dozen XML business libraries, and now it's time for them to start to converge.
XML-J: What would be the effect on e-commerce if there were NOT to be an initiative like UBL?
BOSAK: One of two things. It would either be a lot more expensive and confusing to do e-commerce due to the continuing need to support half a dozen ways of doing the same thing, or a convergence would be forced on us by some big company's assumption of a dominant role. Given enough time struggling with all the adapters and so on needed to deal with multiple languages, people are eventually going to welcome some big player coming in and dictating a solution. So eventually I think we're going to end up with a single XML business library anyway. The question is whether it's going to be developed right now in an open process by a recognized bunch of experts out in the light, where we can all see it and comment on it, or whether it's going to be developed in some back room by a bunch of people concerned mainly with meeting their own product requirements. If it's a proprietary design, it will probably end up full of all kinds of weird hooks that make sense only in terms of where this particular set of developers thought their product was headed at the moment they froze the spec.
I'm for the open process, myself. You get better specifications that way. And if you want a legally binding international standard for commercial documents, which is what we're aiming for in UBL, then I think that development out in the open is really the only way you can make that happen in a way will be acceptable to people all over the world.
XML-J: Will UBL become extinct when ebXML finally arrives? And when might that actually be, do you think?
BOSAK: Let's take that one question at a time. First of all, UBL and ebXML complement each other; they're not competitors. So ebXML is not going to replace UBL. The deliverables promised for ebXML never included a designated XML syntax. The whole project was "syntax neutral” so that the semantic models could be specified in a way that leaves the binding to a specific notation undefined. This lets you produce XML or EDI versions of the data from the same models.
Now if we're only interested in a single XML language for standard business forms, then we can simplify this approach by eliminating that journey out to the abstract layer and just define the data model right in the XML schema. As far as I know, no one has yet identified a data modeling requirement for electronic commerce that can't be met with XML schemas.
The answer to the question of when ebXML will arrive depends on what you mean by "ebXML." It's a big initiative with a lot of pieces. To me, the most interesting parts are the data dictionary and the infrastructure pieces. The data dictionary work is a continuing project that will probably take years to finish, and I expect UBL itself to feed back into that. But the infrastructure pieces are already done. Version 1.0 of the ebXML specifications for secure XML messaging, trading partner agreements, and registries were completed in May 2001. These are standard electronic trading specifications of the United Nations, and they are usable right now. Work on all three specifications is continuing in OASIS, and revised versions are already nearing completion.
Thanks to ebXML, we've now got secure XML messaging built on SOAP, we've got a consensus on how to form trading partner agreements, which can be done either manually or automatically, we've got the basic specification for a very powerful taxonomy-driven registry, we've got a technology for the discovery and classification of core data components in the data dictionary, and we've got a preliminary understanding of how a library of components can be changed to reflect the current business context in which they're being used. If you add a standard syntax to the infrastructure pieces already defined by ebXML, we're ready to rock and roll. So even though the more visionary pieces of ebXML still have a long way to go, for projects over the next few years I personally consider ebXML version 1.0 essentially done, and what I want to see us do is start using it.
XML-J: Why is the OASIS process in particular so well suited, in your view, to a convergence/interoperability challenge like this?
BOSAK: Several reasons, actually. First, the OASIS process has a decentralized management model that makes it easy to get projects underway without a lot of overhead. Second, the process is completely open. All the mail lists are open to public view, and every technical committee has a mail list for public comment that anyone can subscribe to. And third, anyone can join OASIS. It's not limited to big companies. I think that this is essential if what we're designing is going to be accepted as an international business standard.
XML-J: When organizing and leading the original W3C working group that created XML, had you any idea that it would spread through the verticals with the speed that it has done? Or did you think it might happen even faster?
BOSAK: I thought the adoption of XML would happen slowly but inevitably, the way grass grows up through the cracks in the pavement. XML is basically a disruptive, antimonopolistic technology like Java and Linux. I expected tremendous resistance for the first few years, especially from Microsoft. And I think that's just what would have happened if it hadn't been for Jean Paoli, who was the Microsoft rep on the XML working group, and his boss at the time, Adam Bosworth. Adam focused on the data exchange possibilities of XML, which to the rest of us was just one small piece of it, and somehow he and Jean persuaded Microsoft to pick up that part of XML and run with it. That was about the last thing I expected to happen. None of the uses to which XML is being put surprise me at all; everyone involved in the effort had a pretty clear idea of what you could do with XML. The big surprise was seeing Microsoft put its marketing machine behind it.
XML-J: Has your committee had any interaction yet with Microsoft in the process of developing this standard?
BOSAK: Microsoft sent an observer to one of our early organizational meetings, but no one since then. I think it would be really smart of them to be involved in UBL. But I guess you can't expect them to be that quick on the uptake every time.
XML-J: Will .NET have any impact – positive or negative- on UBL?
BOSAK: I don't know enough about .NET to answer that very well. It does seem to me that UBL would fit very nicely into the BizTalk framework, so I suspect that UBL would fit with .NET as well, but it's hard to be sure about that. In messaging terms, UBL is about the payload, not the wrapper. Or to put it in business process terms, it's about standardizing the documents, not the workflow. So my hunch is that UBL won't have any negative impact on .NET and might even help it. As to whether .NET will have an impact on UBL, that probably depends on whether Microsoft is developing a proprietary set of XML schemas for business documents. I don't think that would be a very sensible or productive thing for them to do, but you never know.
XML-J: Are there any plans for an East Coast meeting of the UBL TC any time in 2002? What about elsewhere in the world?
BOSAK: The meeting schedule for the UBL TC is four times a year, twice a year on the west coast of the U.S., once a year on the east coast, and once a year in Europe. The first meeting of 2002 will be hosted by Sun Microsystems 22-25 January in Menlo Park, California. The second meeting will be hosted by the UN/EDIFACT Working Group at their meeting 18-22 March in Barcelona, Spain. We haven't set definite dates and times for the third and fourth meetings yet, but the third one should be back on the West Coast some time in June or July, and the fourth one should be somewhere on the East Coast in September or October. It depends partly on who offers us meeting space. That's why we're on the West Coast a lot -- I know that I can get meeting rooms there.
But that's just the TC itself. We held our first TC meeting a few weeks after the attacks in September, and it was clear by that time that travel was going to be a big problem. So we structured our subcommittees so that they meet mostly by phone and e-mail. If people are interested in participating in the technical work, they shouldn't let travel stop them. They can find out about all this on the TC web site at http://oasis-open.org/committees/ubl.
XML-J: Can you comment on the estimated timeframe you're working with -- how long will it be before it's likely that the UBL transformation rules are formulated and then actually be usable by the targeted businesses?
BOSAK: We're doing two things at once here. We've got one group of people working on the core library and another group working on the context methodology. We originally thought that the content definition would happen first and then we would attack the context methodology; if that's how it goes, I'd estimate about a year for each piece. But if the work can proceed in parallel at about same pace in both groups, we should have a first generation of UBL available in about 18 months. We're hoping to have the very first document type, which will be a purchase order, out for people to look at sometime in February.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week