Re: REXML 2.5.7 and 2.4.7

"Sean Russell" <[e-mail]> wrote in message
news:[e-mail]...
> "MikkelFJ" <[e-mail]> wrote in message
news:<3e596fbf$0$149$[e-mail]>...
> ...
> > Actually I thought it looked so nice that I looked at what program you
> > used - estimating something like emacs - just to discover it was google
:-)
>
> If you're making a funny, it's goin' waaaay over my head.  Google?
> Where did that come from?
>
> Ooooh, you're talking about the *posting*.  I was talking about the
> Germane-Software web pages.  :-)  Yeah, I've been without a real
> Usenet feed for a while.

Nice getting transcripts from live feed ;-)


> As for the G-S website, a friend by the name of David Caley did the
.... snip ...
thanks, I always wonder what people use.

> > By the way, could you be specific on the version of IE, XML and XSLT?
> > Older versions are known to be erhh odd - and the compatibility mode on
> > subsequent upgrades didn't help. I'm no export but I think recent
versions
> > are much better.
>
> Oh, we're probably using something pretty old.  We have a fairly
> recent version of IE for a not-so-recent version of NT on the test
> machines at work.  I can't post version numbers at the moment; the
> closest Windows machine to me is probably in a neighbor's apartment
> somewhere.

Hmm - I could think of  plenty of things to bash Microsoft with, but I'm not
surely is fair in this case. I'm no XSLT expert so I can't judge the current
state. However, I know Microsoft were very actively supporting XSLT in the
early days and for a while were the only with a decent implementation.
However, they did implement and released a working draft spec and probably
added something in order to get something working. Later they released a new
version of the XSLT processor which were more compliant, now the spec. was
released. The problem was that many already were using the old interface.
Therefore, the user could choose to install the new XSLT processor so other
programs by default would use either the old the new interface. Of course
this was a nightmare but eventually the next version did make a point of
using the standard interface. How standard that is, I will let others
judge - I can only say that for a XSLT newbie like I, the ASPX XSLT
integration works pretty neat. I.e. I type some to me completely new syntax
and it generally works out of the box.

Point is - reality bites, especially early adopters. I believe Microsoft in
this case did an honest attempt to cooperate with the industry as a whole
and it is not fair to slam them based on some random version now everyone
has moved on.

> Anyway, I'm not too concerned about supporting IE.  I'm reluctant to
> do a lot of work to get around other people's buggy code.  *Fixing*
> other people's buggy code is one thing, but working around other
> people's commercial, close-sourced, buggy code is another matter
> entirely.

Again - I can find plenty of things to bash Microsoft about - and certainly
the policy about distributing the browser springs to mind. But historically
and technically IE was a godsend compared to a very bloated and buggy
alternative, that had everthing going for it except the knowledge of how to
write programs. With respect to standards, I don't know how compliant
current versions are. I do know that there are plenty of proprietary
extensions - but within the standard it is my impression that the
alternatives, at least until recently were at best equally good at not
conforming to a standard, which in any case were pretty ambigous.

Without blaiming anyone in particular, there are so many differences in the
browsers, that it is fair to choose a single browser based on the intended
audience. Web applications are crappy enough as is, but supporting different
browser versions is a nightmare.
Another point is that web applications are increasingly being used as
desktop application replacements. This puts so much stress on the client
side GUI / event system, in order to avoid unacceptable delays and
roundtrip, that you are forced to depend on subtle details in specific
browser, or alternatively test implement a fair amount of parellel
functionality for each supported browser.

What we need is a completely new replacement of the X-windows standard for
properly building distributed applications over the internet. Meanwhile
Microsoft are probably doing something similar with their .NET strategy. And
personally I don't care as long as my future as software developer is not
tightly coupled with web browsers. I've just closed my first and hopefully
last project this evening.

I believe the primary reasons for web applacations are 1) deployment, 2)
efficient client/server performance. For some to me unknown reason, many
developers can't figure out how to write networked applications without
bogging down in network traffic, unless working writh browsers where they
are forced to reduce the number of client / server operations. Deployment is
easily solved with a click to download thin client for dedicated software -
already happens inside browsers camouflaged as plugins. 2) People should
have learned trick by now.

Mikkel