After spending a week of toil and labor in the Semantic Web mines, I've returned to the surface, to the sweetness and light of the XML developer community. And what do I find but a crisis about the XML part of the technical book publishing industry, as well as a monster thread about character entity names.
I've been beaten up publicly as of late for failing to disclose various affiliations and perceived conflicts of interest. Let me say, then, for the record that I work for O'Reilly as an editor of this site, and that I know very little, if anything about O'Reilly's book publishing business. So now that I've outed myself, let's get to the issue.
The Business ...
Simon St.Laurent -- a book editor for O'Reilly -- started the conversation on the XML-DEV mailing list as a result, or so I suspect, from his having attended various editorial meetings leading up to O'Reilly's FOO Camp earlier in the month. I was fortunate enough to attend one of the FOO Camp presentations which Simon refers to. Indeed, the XML book business is fairly grim across the board, not just for O'Reilly.
That's an important point to think clearly about in my view. After all, O'Reilly as an organization is far from omniscient; in fact, Tim O'Reilly seemed to admit at a FOO Camp presentation that O'Reilly had missed the PHP boat, something others have been saying too. In that case, of course, it was a tricky thing to see, especially for O'Reilly, which has put a ton of effort behind Perl. It particularly tried to pitch Perl as something other than a language for writing cgi-bin Web applications. That must have made PHP's success as a kind of Perl++ in that particular space hard to see coming. One of the most common ways in which people and organizations err is zigging when a zag would have worked better.
... Isn't Doing Very Well
So the first point is that everyone's XML book business is in the dumper. That's the fact which makes this whole issue of interest to more than just O'Reilly employees. If you are inclined to think that the book business is any sort of predictor of technological uptake in general, then you may be worried that sales of XML books are flat at best. I'm not sure that book sales are much of an indicator, at least not in the current economic climate in which technology capital expenditures are, and have been for nearly three years, trending down sharply.
However, XML book sales are down even relative to the downward trends of other technology books. As St.Laurent put it,
XML book sales have dropped substantially, even relative to the overall decline in technology books. A few books dominate the broad (typically though not necessarily beginner) end of the market, while more focused books struggle to achieve the numbers needed to justify their publication.
And the numbers for web services books are even worse.
Possible Reasons, Murky Answers
St.Laurent offers three candidate causes for the decline. First, that XML was overhyped and that wave of enthusiasm has finally foundered on the rock's of XML's disappointment. Second, that there is some measure of standards exhaustion, with W3C XML Schema being something of a key exhauster of developer confidence. Third, that most use of XML is relatively simple usage which doesn't require many more than a few basic books.
St.Laurent thinks about these things as much as anyone I know; hence it might be worth lingering a bit over his candidate reasons. As to the first, I suspect everyone will agree that XML was overhyped. All hype waves eventually exhaust themselves. But St.Laurent adds a claim which many in the XML development community will not agree with -- namely, that the inevitable letdown from the hype was exacerbated by XML failing to be what developers took it to be. That seems as much an indictment of XML as of the fact that XML was overhyped.
As to the second, I tend to agree with St.Laurent about the complexity of specifications being an impediment for many XML developers. Even more to the point, there was something about the W3C XML Schema (WXS) specification in particular which marked a kind of breakpoint in my ability to track carefully the W3C's output. Before WXS I thought I grasped everything of relevance. Since WXS I have had to pick my spots more carefully. Maybe WXS doesn't deserve the blame, but it's as good as place as any to place it, in my view.
As to the third, I think St.Laurent is exactly right here; and I will only point out that the second and third reasons work together in interesting ways. That some kind of XML core is very useful, and very often used, suggests that the W3C -- and here I mean the prime mover member organizations, most of which are enormous corporations -- may have missed the boat in aggressively pursuing more complex, less used permutations.
To St.Laurent's list of candidate reasons, I add the maturity of the Web as an informal publishing medium. Despite O'Reilly's investment in sites like XML.com, I would be very surprised if the Web doesn't still keep folks there up nights worrying about technical book sales dwindling and never recovering. Book publishers will deny this -- and maybe they're right -- but good enough is often enough when it comes to technical material. For any reasonably interesting computing technology the Web often contains enough information which is good enough to get most technical workers over the hump. Even worse, much of that information is published informally, which is to say that it's not really published at all, it's just there, and it's certainly not there for a profit motive. I think there's a future yet in technical book publishing, but it's probably going to be different than the past.
Chris Wilper makes this point in an amusing way:
The truth is, I can almost always find the reference material I need online, with the added bonus of mailing list archives. The tactile experience of books is the only thing I miss.
Oh, and the smell.
Wilper's experience exactly echoes my own. The number of tech books I've bought is inversely proportional to my technical skills. I am, as Wilper hints he may be, a serious book junkie. I love the damn things, to the tune of having more than 3,000 volumes in my library. The Web has meant I can focus my bookish acquisitive desires on stuff other than the technical. I can nearly always find something good enough on the Web about the latest XML or Python or Linux or Semantic Web doodad.
In a followup message, St.Laurent speculated as to the reasons why XML developers, particularly the kind of junkies and addicts who haunt XML-DEV, aren't buying more books, again offering three. First, a mismatch between the kinds of XML books published, typically targeted at beginners, and the advanced status of some XML developers. Second, the dispersion of interests as people move from beginner to advanced status. As Simon puts it, "I've tried, but not all niches are sustainable". Which is too bad, of course, because for many of us the really interesting stuff is stuff that has, necessarily and unavoidably, a small audience. Thus, doing something to lower the cost of producing a new book -- or finding a new genre of publication which is (a) cheaper and quicker to produce than a book; (b) more substantial than a long web article; (c) targeted at these interesting niches; and (d) not insanely expensive -- might help the bottom line. Third, technical books sometimes suck. That's a hard truth, but a truth nonetheless. I don't think O'Reilly is worse in this regard than other publishers; in fact, O'Reilly is better than most other publishers in this regard. But sometimes, as the waves of hype crash over and over us, in early days, we lose our way and become disoriented. That's not so good for quality control.
Exacerbating all these issues is the fog of book publishing. It's not easy for publishers to know why people do or do not buy technical books; in fact, I think it may be harder to technical publishers to figure this out than for, say, publishers of fiction. Taste is more fickle, but less complex, than necessity. It can even be difficult to know how many books end up in the hands of actual readers, given that publishers sell to retailers, not to readers. My impression is that the folks at O'Reilly have worked hard to solve this problem, and that they still have more questions than answers.
Share your comments on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Full Threads | Newest First |
- Missing XML books
2003-12-11 19:24:42 Bob Wilmes [Reply]
I personally wish someone would write a book on JAXB and the related JAX* Java API's.
I am also waiting for a BPEL4WS book which connects business process design to that XML dialect.
- Book Junkie
2003-11-21 10:17:47 larry bradshaw [Reply]
I can relate. I have fifty Oracle books, if I have even one. Still have twenty or thirty DOS books.
Concepts and ideas are my business. More so than the software that embodies them. So let me solve this problem for you. Or at least try to!!
What I would pay for would have to offer:
- secure online access to "published" materials. It has to be SSL access or better. I am tracked by lots of people any time I set foot on the web. Both people who like me and people who do not like me. Some of these are competitors. I will never willingly announce to my competition which books I am reading, when, or why.
- A better experience than hard copy text reading. A better experience than mailing list or web reference mining.
- A more current and state of the art status than any other media.
- Links to other related info, related books, and perhaps direct contact with authors. Years after the fact, authors have informed me that feedback they received directly or indirectly from me was highly valuable to them. I could have used their feedback to my feedback, years previously.
- More affordable than my current hardbound library investment.
- More usable, more effective than my office library.
So. Lets see where that leaves us:
1) An online service, which I may need to access from anywhere, anytime.
2) Current, updated, state of the art information for all information provided. No aging.
3) Cost effective. Not as stringent as it sounds, since my average monthly cost for books is in the hundreds of dollars a month, all together.
4) Cross-spectrum, cross-publisher, the entire printed universe as a content population.
5) Searchable, cross referenceable, criss-crossable and multi-volume open at the same time able.
6) Related links, with perhaps a real time RSS feed on blogs (with entries as sub items, searchable).
7) Connections to authors and principal investigators (scientists).
8) Taggable. So I can bookmark, annotate, and return as I please.
9) Secure, or relatively so. SSL at least. Maybe better.
Hmmmm. Lets ponder for a moment. If we consider book and blob and email newsletters and xml-dev type lists as database line items or object entries, and think of a pure java access interface (gui, run anywhere) with an xml transport layer (many to many middleware capable), I think we have it.
Problem solved?
Not as hard as what the Library of Congress is busy doing, I think.
Let me know if this helped you, Ok?
Thanks!
Larry
- Books vs. Mailing list archives
2003-11-20 17:03:43 Shunhui Zhu [Reply]
I think this is in general true: when you want to learn something, read a book; when you want to use it, search the mail archives. Most
financially viable books (meaning enough sales)
are for beginners. Once one goes beyond the basics, one at most needs something like a cookbook (the best: O'reilly's Perl Cookbook), mail archives are much more useful.
I see the main special problem with XML's book trouble is that the basics are very simple, and most people only need the basics.
- XML is a disappointment
2003-11-20 02:14:59 Michael Grazebrook [Reply]
XML is a disappointment for me. At a business level, the need for a set of common standards for data interchange is vast and important. But why oh why was it done like this?
Over the past couple of decades I've worked with many data formats, and XML / XSLT is one of the less readable ways to present data. It's really hard to provide layout which makes an XML document readable without transformation.
This gets worse when dealing with XSLT for use with XHTML. The code and the content (XHTML tags) are hopelessly intertwined. Modularity - one of the foundation stones of development - is out the window as a result.
And yet - the business need is powerful. XML Schema is indeed hard to understand (and I write as one who has written schema processors).
But the schema for an industry - an agreed definition of the data standards for a domain - is something of immense power. With standards like MPEG-7 (multimedia), DIG-35 (cameras), FPML (financial products), SWIFT (financial back office) - the data architecture of an indistry is laid bare.
And the data architecture of an industry lets me develop applications for that industry in a fraction of the time it would normally take.
I can generate the database. Class libraries. Data input screens. Reports. All with a little manipulation of the schema. All knowing that there will be no problem with incompatibilities.
With change reduced by the perfection of the initial analysis in the schema, shining gems of analysis crystallized in the hard form of a specification agreed by an industry.
And THIS is what none of the books teach me.
- We need more "why-to" and less "how-to"
2003-11-13 12:26:02 Peter Brown [Reply]
When I decided to write on XML, I realised there was a big gap in selling the idea of XML to:
- non technical communities, particularly senior management; and
- technical communities, for whom XML was a bloated alternative to their particular nifty approach.
Getting both to understand that XML is part of putting information assets centre-stage in a business strategy - as I have argued - seems to have hit a positive note.
My contribution was modest, but I do wonder whether maybe XML has been overplayed as "the" syntactic solution to all our woes, hence the sense of overload of too many books on this aspect, and underplayed as a business tool.
The Kotok and Webber book on ebXML seems to go in this sense too: would be interesting to see how that flies
- Hope it was just the economy
2003-11-05 11:03:44 Ken Bluttman [Reply]
Gee, what a downer reading this, especially since I have a book coming out next month on Office 2003 and XML.
I too have buy more computer books than I can possibly read through. There is no replacement for holding a book in your hands. Isn't this the cause of e-books not taking off?
XML overhyped? What isn't? Does it do the intended job? It does for me, but then again there are developers who don't know and therefore don't use it, but the get the job done too.
I like the portability and lack of vendor specific control offered by XML. Too often I have had to get Oracle, SQL Server, Sybase, Access, or FoxPro to all behave with each other. Using XSLT and XML seems to smooth the bumps. In fact, perhaps the focus on XML is not as important as the focus on XSLT. Here at least we have a programming language (well, sort of).
- XML is only a tool...
2003-11-03 05:22:17 john fraser [Reply]
XML is a very powerful and very simple tool. Once you learn the basics, you can apply it to many areas with ease.
Many of the XML specifications are to complex - if it takes me more than an hour I'm not interested. I'll invent my own based on need and transform it to something else if I have to.
Basic XML + XSLT can do anything you want.
- XML problem is that it's hard to generate XML
2003-11-02 12:05:59 Mark Wilcox [Reply]
The hardest part of XML for mainstream users (which is regardless of development language ) is that it's hard to generate XML in any particular syntax because the standard reporting tools - such as Excel don't have an easy to way to generate XML documents that match particular XML schemas.
- We did this with ASN.1...
2003-11-01 13:37:19 Bob Wyman [Reply]
For parallels to the current "XML exhaustion" all you have to do is remember ASN.1 which back in the 80's promised exactly the same benefits as XML (except that ASN.1 had compact encoding...) to the fathers of many of today's XML programmers. When ASN.1 first got started, it was hailed as a solution to all problems -- particularly the problem of interchange between systems. However, what started as something which was pretty simple soon became very complex (i.e. macros, etc.). The coming of XML Schema did pretty much the same to XML. We've been here before...
These days, I find myself translating XML Schemas to ASN.1 so that I can internally use compact encodings like PER while externally exchanging XML. Dealing with two complex but equivelant specs where one is all that should be necessary... Grumble. Why do we keep reinventing the wheel?
bob wyman
- XML's problem
2003-10-31 11:52:57 Bernard Duffy [Reply]
XML tries to be all things to all people to the point that it becomes meaningless gibberish.
When it comes down to it, XML is serialized data with inline descriptors. Big whoop. XMLized data is bigger thanks to all of the markup and requires more computing resources to process all of the meta information.
And the much-touted "XML is a universal means of exchanging data" is a red herring as well. Markup in an XML file does not transfer understanding of what the data means -- and that is the key thing.
- XML should solve a problem
2003-10-30 01:38:49 Rinie Kervel [Reply]
Just my personal view. But books and articles often use a technology because it exists, not to solve realworld problems. Basic XML formats (e.g. XUL or config files) are clear, not very verbose and both easily understood by humans as by computers.
XML schemas or regular expressions are hard to read for non programmers. SAX is hard to use and there is no intuitive way programs should read and write XML (as means of serialisation for instance).
I feel that using XML 2 things should be separated:
- Is the input valid XML for my Schema (should be checked automatically, not in my code)
- Processing the XML data
Furthermore:
- Is serialization a dump of my programs object state or a human readable interface format between different applications, written in different languages. This becomes worse if you couple a relational database (SQL), a prgramming language (objects in Java,C#, Python or Perl) and a XML file:
- Is the XML serialized SQl, serialize Java objects or an XML format that can be stored in Java objects or SQL tables.
Also from a Windows perspective Java, Perl or Python are not mainstream tools (and I dislike the everything should be in Java approach).
Just my thoughts
