Cart
[Home] [By Thread] [By Date] [Recent Entries]
Elliotte asks: > What do people think is going to happen in 2007 in XML? What are we > going to talk about for the next 12 months? Which new technologies are > going to birth industries? Which ones are going to flop? What are your > predictions? Speaking just for myself (as opposed to IBM, the TAG, etc.): I'm afraid that in 2007 those who value practical, compatible, easy-to-use, traditional HTML and those who value more strictly architected, extensible XML-based HTML may continue to talk past each other to a degree that's unfortunate. Both sides are "right", in my opinion, though each in their own way. Most all of the things that WHATWG and friends say have merit. Compatibility is a big deal, especially with a system deployed to hundreds of millions. Ease of authoring is a big deal. Simplicity is a big deal (though you can argue intelligently that either the tag-soup HTML design or the XHTML design is simpler, depending on your goals and the design points of interest.) That said, I think that whatever serves as the document format for the Web will need to evolve quite a bit over the next decade or two. Technology will change. Expectations for rendering quality, layout, navigation, perhaps animation, or perhaps other things we can't quite anticipate will change too. While [XML+Namespaces+HTML=XHTML compound documents] is far from perfect, you can argue that it provides a more robust framework for >distributed< innovation; it provides richer tools for evolving what a Web document is. That's a big deal too, in my opinion, and I'm not convinced it's getting enough attention from those who are focussing more on the realities of building browsers today. Finding a sweet spot that adequately meets all of these needs is going to be tough. I think it's worth trying. On a related point, all appearances are that the data-focussed and document-focussed XML camps will also continue to talk past each other to a certain degree, though with perhaps in a bit calmer style than the HTML folks. That's also too bad, in my opinion, because I firmly believe that the areas where these styles intersect is uniquely interesting. Some of that belief comes from over a decade of playing with Lotus Notes, a system that predates the Web and XML (though not SGML), but which shares a lot with the Web, XML and HTML in its architecture. It too is a system in which everything is a document. It's a system in which every document is a set of typed name/value pairs, though unlike XML, it's a flat list not a tree. Like the XML model, the application uses a strong model/view separation, with information-only documents being rendered under the control of other stylesheet documents (which Notes calls Forms). At the time Notes rose to prominence, users were making a tremendous investment in relational databases. What Notes showed, to take an example I've often used, is that you don't just want a database that can store a list of insurance policy holders, you want a system that can deal with the insurance policy document as well. You want that policy to be a smart document, in which the customer's name, policy number and coverage limits can be integrated with the policy document itself, not just to fill in those fields, but to by dynamically restructuring the document according to the data being processed. You want a system in which you have a description language that can unify the description and typing of both the policy data and the document template, and a transformation system that can manipulate all of that. XML gives you that. With the XML stack, you can use the same schema language to describe the customer list, the policy document template, or the policy document for any particular customer. The same xs:decimal type that describes the amount of coverage in the customer list describes it in the policy document template, and in the document that results from applying the template. The template or the completed documents can be stored in the same XML database as the policy holder lists, and XQuery can do joins over the lot of it. That's all a big deal. I hope the data and document camps keep in touch in 2007. It would be a shame if XML split into two systems that happened to share some technology piece parts. As others have pointed out, the WHATWG vs. XHTML discussions are just an example of the "XML is too complicated" backlash. I personally think that there are reasonable XML idioms (probably close to the subset) that are simple enough for many purposes, but I certainly don't want to get into the debate in detail here. If JSON makes people happy, for good or bad reasons (I think we're seeing both), fine. When all is said and done, there is still tremendous value in a single metamodel that handles both documents and data pretty well. XML does that. (JSON doesn't, from what I can tell.) For all its warts, I think XML will continue to do just fine overall in coming years. I do think there will be a push to simplify the stack, though perhaps by writing in idioms that are simple, as much as by changing the cores standards. I think we'll see lots of activity and debate regarding all of these issues in 2007. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
