[
Lists Home |
Date Index |
Thread Index
]
jonathan.robie@datadirect-technologies.com (Jonathan Robie) writes:
>>[Roger Costello]
>>Your XSLT book now stands at 938 pages. How big will it be for XSLT
>>2.0? 1500 pages? Can a technology which takes 1500 pages to describe
>>truly be considered a "Web technology"?
>
>Is the XSLT 1.0 described by Mike Kay's book in 938 pages more complex
>than the XSLT 1.0 described by the specification in 45 pages? Are you
>suggesting that the number of pages you conjecture might be needed in
>a future edition of a book by Michael Kay be used as a serious metric
>of the complexity of the language?
This is an especially tough problem for those of us who earn our livings
writing and editing books on these subjects.
When I wrote the first edition of XML:A Primer, the book was 350 pages
long and covered the XML 1.0 spec in depth, with some coverage of XLink
and the XSL Working Draft. I was able to spend a huge amount of space
doing exegesis of the spec and explaining what XML could do. The second
edition covered more territory in 407 pages, reflecting extra content on
namespaces and more on XSL, as well as a shift to cover more
programmer-oriented topics. The third edition (which seems to have
largely disappeared in the collapse of Hungry Minds near its pub date)
is 550 pages, with the extra 150 mostly representing very brief
introductions to XSLT, W3C XML Schema, and RELAX.
I don't think it is possible at this point to write a "general XML book"
that covers all of the surrounding specs. _XML in a Nutshell_, by
Elliotte Rusty Harold and Scott Means, manages to provide a solid
overview in 480 dense pages, while Ken Sall's _XML Family of
Specifications: A Practical Guide_ comes in at 1100 (less-dense) pages
plus an excellent poster. Both of these cover more pages in
specifications that their actual page count, so we've definitely crossed
from books as extended explanation to books as condensed content.
(Sadly, authors who publish on subsets of specs are usually assaulted
for it by angry reviewers who can't find details about their favorite
feature or a nit that makes it hard for them to use a tool they've been
given.)
There's that classic comment about "it would have been shorter, but I
didn't have time". I worry both that we're not taking that kind of time
with the specifications coming out. That means it's growing harder and
harder both to write about these subjects (since so much turns into
condensed summary) and to sell the books, internally (for proposals) and
externally (to customers).
The perceived barriers to entry in XML beyond really basic markup have
grown much faster than the perceived benefits, and it makes it a much
harder sell than it used to be.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
