Re: MSXML abominations happening for a reason (was Re:MSXML.

> Yes, the problem is that pure XML/XSLT is too hard for your average "HTML
> programmer" to master in short order, in part because its functionality is
> less than obvious (side effect free operations on and specified by
> abstract trees derived from documents, rather than markup as direct
> controls for browser behavior).

I completely agree.  It's not that XSLT is too difficult to learn (many
web designers have learned JavaScript, itself a scripting language), but
that they don't see the benefits of XML/XSLT.  I'm sure many think their
jobs are for writing HTML and getting it to work on all the browsers.  To
them, the concepts of the content and the structure and look&feel are
wrapped up in one (the HTML).  I also think that they don't see where HTML
fails, which is why they aren't looking around for
"better" technologies.  To them, HTML seems to get the job done (stuff
shows up on the browser, doesn't it?), so why should they go and learn XML
(which itself have many parts) and XSLT?  Why should they separate their
content and their logic and their look&feel when they are hitting a
database via ASP, putting the results in HTML, and sending it to
client?  That seems to work just fine for them.

Until web designers or web engineers understand the benefits of
creating a decoupled solution with XML/XSLT they won't clamor for fully
functional tools.  Sure, the MSXML thing is terrible, but is anyone going
to use it anyway?  Maybe Microsoft's job shouldn't just be to release
fully comformant tools, but to also educate and promote the new
technologies?

my two cents,
Seth


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list