RE: [xml-dev] 2007 Predictions

[noah_mendelsohn@us.ibm.com]

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
--------------------------------------