[
Lists Home |
Date Index |
Thread Index
]
I go back to my previous point - if this gets too big it'll never be
really used except by enthusiasts
C is successful because it's both small - and therefore can be easily
understood - and complete.
SQL is relatively small, and based on very sound mathematics (as is C).
To my mind, XML 1.0 and XSLT 1.0 are complete, simple, and very
powerful. As a language independent description of something XML is
bulky, but effective because of it's neutrality. XSLT as a preprocessor
to a target language or display completes a very nice pairing.
My personal test of the soundness of programming languages and
techniques is that i should be able to use them without constant
reference to a manual or a "tool to make it easy". therefore i don't use
java, dislike many modern graphic environments and development tools,
and fear for the future of this great technology.
the simple formula for measuring all this has to installed and working
software (however it's measured) vs man hours to produce it. so there
has to be a lot of productivity to make constant reference to 1000 page
manuals worthwhile.
rick marshall
On Thu, 2003-06-12 at 07:17, Simon St.Laurent wrote:
> 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.
|
