Slashdot Mirror

Anyhow, what you've got to get through your mind is that XSLT is a functional language; it's not procedural. We're not in Kansas anymore, Toto. Functional languages are a different beast than what you're used to, i.e. procedural languages.

If you've taken a CS course on programming languages and they covered functional languages well than you don't have to learn anything, just realize that XSLT is functional and program accordingly.

If you haven't taken a CS programming languages course or didn't cover functional languages then you need to learn the functional paradigm. Think transformation, not variable assignment. Think functional composition, not a row of statements. Think recursion, not looping.

To learn it yourself, you're going to need a good book on functional programming, such as Haskell or Erlang. Both have open-source implementations available. This is not something you're going to learn in a day, it will take you a month of diligent study before you understand what you're doing. If you know rigorous logic well and are adept in discrete math and set theory you'll advance more readily.

In addition to learning functional programming, you'll have to learn the quirks of XSLT. For one, you need to have mastery of the specs for XML, XPath, and of course XSLT. Al these specs are quite readable: read them through, try out examples. You also need to be aware of the limitation of XSLT, especially in these early days of the 1.0 version (2.0 should be more useful). Often you'll need to either do processing before/after XSLT with Perl or something else, or directly incorporate JavaScript into your XSLT document. Be sure to understand inclusions and use XSLT library documents with useful functions.

Once you understand functional languages in general and XSLT in particular you'll be on your way to mastery of XSLT. You'll also learn alot along the way that will be useful even if you never touch XSLT again. In addition, you'll have experience in the maxim uttered by other posters that you must use the right tool for the right job. XSLT is superb for most common XML transformations (such as XML to HTML) and is far better than any other languages for doing this. But sometimes you need something else like Perl or Java for direct manipulation. Use the right tool for the right job.

Anyhow, what you've got to get through your mind is that XSLT is a functional language; it's not procedural. We're not in Kansas anymore, Toto. Functional languages are a different beast than what you're used to, i.e. procedural languages.

If you've taken a CS course on programming languages and they covered functional languages well than you don't have to learn anything, just realize that XSLT is functional and program accordingly.

If you haven't taken a CS programming languages course or didn't cover functional languages then you need to learn the functional paradigm. Think transformation, not variable assignment. Think functional composition, not a row of statements. Think recursion, not looping.

To learn it yourself, you're going to need a good book on functional programming, such as Haskell or Erlang. Both have open-source implementations available. This is not something you're going to learn in a day, it will take you a month of diligent study before you understand what you're doing. If you know rigorous logic well and are adept in discrete math and set theory you'll advance more readily.

In addition to learning functional programming, you'll have to learn the quirks of XSLT. For one, you need to have mastery of the specs for XML, XPath, and of course XSLT. Al these specs are quite readable: read them through, try out examples. You also need to be aware of the limitation of XSLT, especially in these early days of the 1.0 version (2.0 should be more useful). Often you'll need to either do processing before/after XSLT with Perl or something else, or directly incorporate JavaScript into your XSLT document. Be sure to understand inclusions and use XSLT library documents with useful functions.

Once you understand functional languages in general and XSLT in particular you'll be on your way to mastery of XSLT. You'll also learn alot along the way that will be useful even if you never touch XSLT again. In addition, you'll have experience in the maxim uttered by other posters that you must use the right tool for the right job. XSLT is superb for most common XML transformations (such as XML to HTML) and is far better than any other languages for doing this. But sometimes you need something else like Perl or Java for direct manipulation. Use the right tool for the right job.

So the short answer to your question is : no, XSL is not the right choice to do procedural logic.

Functional programming requires a completely different mode of thinking than procedural programming. Anybody who understands the definition of "procedure" in ordinary English understands the procedural programming paradigm, even if they don't know the technical details. But the functional programming paradigm is a lot less commonplace, and takes some getting used to. Before tackling XSLT, it might make sense to try to pick up some fundamental FP concepts. One way to do this would be to work through the leading functional programming textbook. (It says a lot about MIT that they've gone and made the entire book available online!)

It is kind of irritating that XSLT's creators decreed that a syntactically correct XSLT program had to be a well-formed XML document -- and thus rather verbose. But that sort of thing rather goes with the FP mindset -- FP source is supposed to be easily transformable using the same language it's written in. That's why there are Lots of Insipid Silly Parentheses -- and so few syntax rules -- in languages like Scheme.

It's worth mentioning that Perl, though basically a procedural language, has some of the same design philosophy as the FP languages. It's easier to code a simple loop in Perl than in an FP language -- but Perl has as many ways to avoid coding a loop as any FP language!

Also worth mentioning that XSLT and XSL are not quite the same thing. XSLT is the transformation language for XSL. It's a relatively recent invention. As originally conceived by Microsoft (yep, the evil empire was the biggest partner in drawing up the original XSL spec), transformation languages were a mix-and-match affair. A lot of early examples had XSL stylesheets with embedded Visual Basic code!

Come to think of it, it wouldn't be hard to do a stylesheet language based on Perl, or to evolve a convention for embedding Perl instead of XSLT in XSL stylesheets. Now, why do you suppose nobody is working on that. Uh, that's a rhetorical/socratic question!

It is important to remember that XML is not a programming language, it is a data format. XSL is also not a procedural language, it is a language for formatting data into a stylesheet. I refer you to the XSL page of the w3 :

XSL is a language for expressing stylesheets. It consists of three parts: XSL Transformations (XSLT): a language for transforming XML documents, the XML Path Language (XPath), an expression language used by XSLT to access or refer to parts of an XML document. (XPath is also used by the XML Linking specification). The third part is XSL Formatting Objects: an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. For a more detailed explanation of how XSL works, see the What Is XSL page.

So the short answer to your question is : no, XSL is not the right choice to do procedural logic. If you are doing something with your data other than displaying/formatting it, use something other than XSL. (Perl, Python, JSP, ASP, etc)

I only started seriously looking into "web services" yesterday, so I'm a newbie. However, I think I can poke some holes in the poster's arguments.

They also require that a Web Services directory server (UDDI) be available

You don't need a UDDI server to run "web services," whatever they are. Google's SOAP service seems to work just fine without the use of a UDDI server. You don't need a discovery server if you've already discovered the service you want to use.

No standards yet exist for Web Service security

How about SSL, HTTP BASIC-AUTH, XML Signature, Digital Signature for SOAP, SOAP Encryption, XML Key Management Specification... Also in the news recently is a major proposal, WS-Security. Also read the press release about other upcoming proposals. I don't know a lot about many of these specs, because as I said, I've only been looking into this stuff for one day. However, it looks like there is a lot of effort here, so if some of the standards aren't quite here yet, it looks like they will be soon.

Because Web Services require multiple HTTP (request-response)s across the Internet, they are inherently 1000's of times slower than an API call on a local machine.

"Web services" don't require HTTP at all. And, since the obvious point of the whole exercise is to communicate with other systems on a network, pointing out that calls are slower than on a local machine is pointless. You know, web browsing to a machine across the Internet is also inherently 1000's of times slower than browsing on your own machine--yet seems to be popular. There are also techniques like WSIF for invoking web services where the client and the server could be on the same virtual machine, if appropriate.

Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.

I don't know much about this one either, but it doesn't make sense on the face of it. The whole idea of defining a common wire protocol like SOAP is for interoperability. Maybe it's true, but it seems like anyone who makes such an implementation is doomed to have their implementation sit unused. Of course, if you are Microsoft, you might be able to pull it off...

All this pales when one considers the effort involved in getting the IT groups of two cooperating corporations to agree on what a term such as "business partner" means and how it is to be represented in XML and/or a database.

I suppose this would have to happen in any integration effort of any kind, so it doesn't seem to be a convincing argument against "web services" (unless you are opposed to integration on general principles).

Today, remote procedure calls are used on the Internet, but not nearly as often as local procedure calls, and certainly not nearly as often as Web Services Proponents would have you believe. A world of Web Services would attempt to distribute processing across the internet, and would fail miserably. Contrary to the premises of the Web Services architecture, the only viable future architectures are those that integrate and centralize processing and that minimize remote procedure calls.

It seems like this is the same thing that web servers do today. However, instead of a human user sitting in front of a GUI initiating every request and consuming the data, "web services" let computer programs initiate the requests and consume the data. Why should this be intrinsically doomed to failure when done with "web services" in a computer program, when it seems to work pretty well for the human user of a web browser?

I dunno, just seems like the poster got up on the wrong side of the bed or something. I'm no "web services" zealot, but it seems like there is a lot more potential there than the poster thinks.

I only started seriously looking into "web services" yesterday, so I'm a newbie. However, I think I can poke some holes in the poster's arguments.

They also require that a Web Services directory server (UDDI) be available

You don't need a UDDI server to run "web services," whatever they are. Google's SOAP service seems to work just fine without the use of a UDDI server. You don't need a discovery server if you've already discovered the service you want to use.

No standards yet exist for Web Service security

How about SSL, HTTP BASIC-AUTH, XML Signature, Digital Signature for SOAP, SOAP Encryption, XML Key Management Specification... Also in the news recently is a major proposal, WS-Security. Also read the press release about other upcoming proposals. I don't know a lot about many of these specs, because as I said, I've only been looking into this stuff for one day. However, it looks like there is a lot of effort here, so if some of the standards aren't quite here yet, it looks like they will be soon.

Because Web Services require multiple HTTP (request-response)s across the Internet, they are inherently 1000's of times slower than an API call on a local machine.

"Web services" don't require HTTP at all. And, since the obvious point of the whole exercise is to communicate with other systems on a network, pointing out that calls are slower than on a local machine is pointless. You know, web browsing to a machine across the Internet is also inherently 1000's of times slower than browsing on your own machine--yet seems to be popular. There are also techniques like WSIF for invoking web services where the client and the server could be on the same virtual machine, if appropriate.

Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.

I don't know much about this one either, but it doesn't make sense on the face of it. The whole idea of defining a common wire protocol like SOAP is for interoperability. Maybe it's true, but it seems like anyone who makes such an implementation is doomed to have their implementation sit unused. Of course, if you are Microsoft, you might be able to pull it off...

All this pales when one considers the effort involved in getting the IT groups of two cooperating corporations to agree on what a term such as "business partner" means and how it is to be represented in XML and/or a database.

I suppose this would have to happen in any integration effort of any kind, so it doesn't seem to be a convincing argument against "web services" (unless you are opposed to integration on general principles).

Today, remote procedure calls are used on the Internet, but not nearly as often as local procedure calls, and certainly not nearly as often as Web Services Proponents would have you believe. A world of Web Services would attempt to distribute processing across the internet, and would fail miserably. Contrary to the premises of the Web Services architecture, the only viable future architectures are those that integrate and centralize processing and that minimize remote procedure calls.

It seems like this is the same thing that web servers do today. However, instead of a human user sitting in front of a GUI initiating every request and consuming the data, "web services" let computer programs initiate the requests and consume the data. Why should this be intrinsically doomed to failure when done with "web services" in a computer program, when it seems to work pretty well for the human user of a web browser?

I dunno, just seems like the poster got up on the wrong side of the bed or something. I'm no "web services" zealot, but it seems like there is a lot more potential there than the poster thinks.

I only started seriously looking into "web services" yesterday, so I'm a newbie. However, I think I can poke some holes in the poster's arguments.

They also require that a Web Services directory server (UDDI) be available

You don't need a UDDI server to run "web services," whatever they are. Google's SOAP service seems to work just fine without the use of a UDDI server. You don't need a discovery server if you've already discovered the service you want to use.

No standards yet exist for Web Service security

How about SSL, HTTP BASIC-AUTH, XML Signature, Digital Signature for SOAP, SOAP Encryption, XML Key Management Specification... Also in the news recently is a major proposal, WS-Security. Also read the press release about other upcoming proposals. I don't know a lot about many of these specs, because as I said, I've only been looking into this stuff for one day. However, it looks like there is a lot of effort here, so if some of the standards aren't quite here yet, it looks like they will be soon.

Because Web Services require multiple HTTP (request-response)s across the Internet, they are inherently 1000's of times slower than an API call on a local machine.

"Web services" don't require HTTP at all. And, since the obvious point of the whole exercise is to communicate with other systems on a network, pointing out that calls are slower than on a local machine is pointless. You know, web browsing to a machine across the Internet is also inherently 1000's of times slower than browsing on your own machine--yet seems to be popular. There are also techniques like WSIF for invoking web services where the client and the server could be on the same virtual machine, if appropriate.

Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.

I don't know much about this one either, but it doesn't make sense on the face of it. The whole idea of defining a common wire protocol like SOAP is for interoperability. Maybe it's true, but it seems like anyone who makes such an implementation is doomed to have their implementation sit unused. Of course, if you are Microsoft, you might be able to pull it off...

All this pales when one considers the effort involved in getting the IT groups of two cooperating corporations to agree on what a term such as "business partner" means and how it is to be represented in XML and/or a database.

I suppose this would have to happen in any integration effort of any kind, so it doesn't seem to be a convincing argument against "web services" (unless you are opposed to integration on general principles).

Today, remote procedure calls are used on the Internet, but not nearly as often as local procedure calls, and certainly not nearly as often as Web Services Proponents would have you believe. A world of Web Services would attempt to distribute processing across the internet, and would fail miserably. Contrary to the premises of the Web Services architecture, the only viable future architectures are those that integrate and centralize processing and that minimize remote procedure calls.

It seems like this is the same thing that web servers do today. However, instead of a human user sitting in front of a GUI initiating every request and consuming the data, "web services" let computer programs initiate the requests and consume the data. Why should this be intrinsically doomed to failure when done with "web services" in a computer program, when it seems to work pretty well for the human user of a web browser?

I dunno, just seems like the poster got up on the wrong side of the bed or something. I'm no "web services" zealot, but it seems like there is a lot more potential there than the poster thinks.

Mo. Namespaces allow nothing of the sort - an XML Document cannot contain another XML Document, with or without namespaces.

This is why HP came up with the hack of putting SOAP messages in mutipart-MIME wrappers - this was necessary to pass XML Docs as arguments in a SOAP doc. Your Jabber stream is using a similar wrapper - a wrapper which is not XML.

As we all remember from college, most protocols are layered, which allows encrypted bits to be layered inside routing / security bits, but an XML document can't be layered (it can't contain other XML documents).

As all the current college students know, XML Namespaces allow layering or otherwise blending of various XML applications. For example, some solutions can pass XML-RPC or SOAP payloads in Jabber messages, thus building on top of the Jabber message passing, presence and authentication framework.

Your understanding of XML, "...XML is nothing more than formatted text -- utterly devoid of value until two or more parties agree on a shared vocabulary (in the form of a DTD or Schema" is exactly what XML is defined to be. See? Point #2 is probably the most appropriate here.

Web Services: the stuff that dreams are made of, or more hype from our
favorite technology gurus?

"You can say this has been a dream of computer
science for many decades. The momentum is there to drive [Web services] to the
same kind of central position that the graphics interface and HTML had across
all the different systems in the past." -- Bill Gates (Source: Informationweek.com,
Feb 11, 2002)

In all the battles that Microsoft has had, the one that
has been disproportionately ignored by the technology media relative to its effect
on Microsoft's hopes and ambitions would have to be Microsoft vs. The Internet.
J2EE, Linux, open source and countless other fears of The Stronghold have taken
the show, while few have noticed the potential fundamental impact of the Internet
on Microsoft's business strategy. Microsoft loudly acknowledged the Internet around
1994, pointing out what a good thing it was, hoping that they would be able to
come up with a strategy to defend itself before people realized the Internet was
going to give Microsoft its greatest challenge. The distraction appears to have
worked, as few have considered the consequences this quantum leap in technical
progress could have on this industry giant. To technology purists, the Internet
was about open standards, connectivity, interoperability, peer-to-peer, and, inevitably,
distributed computing. While each of these arrows has threatened to chip away
at Microsoft's proprietary closed Windows platform, none has promised to devalue
the individual machine, Microsoft's pinnacle of success, more than distributed
computing. What became clear in the browser wars was that open standards was the
only way to win any war on the Internet. One may be able to truthfully say that
Microsoft has won the browser wars. Yet, what is also true is that the browser
has just enough holes through the open standards to ensure that no one can stop
the flood of new competitive technologies and open standards from leaking through
it. In this respect, open standards won the browser wars, even if we have to live
with a few idiosyncrasies that can make our browsers a bit obnoxious. Distributed
computing is about getting components and systems to interoperate to create something
bigger, independent of the physical machines the parts are hosted on. As each
computer reaches out to connect to another to create something bigger, the individual
machine becomes less noticeable. It becomes just one of thousands, then millions,
then billions of machines in a world of massive information flows to create what
we call the Internet. In order for this to happen, it was clear to all players
we would have to agree on the standards used to integrate all the components and
processes. While Microsoft had a chance of winning browser wars, in part because
the standards, notably HTTP and initial versions of HTML, were already defined,
and the browser is a user interface on, yes, the individual machine, distributed
computing promises to be different. In the new architecture, value will be defined
by the sum of the [distributed] parts. The ability to participate will define
the value of each piece of code. Aware that this phenomenon was inevitable, there
wasn't a single heavyweight in the industry willing to let Microsoft control how
all the world's computers and components were to connect to create this new era.
IBM, Oracle, Sun, HP, and countless others, with plenty of experience working
on projects to erode Microsoft's influence, were determined to doom any efforts
by Microsoft to control the standard protocols. With everyone willing to agree
on open standards, if, for no other reason, to ensure that Microsoft did not have
a chance, even Microsoft had to concede that the standards would have to be open,
and accepted by all major parties. We call the package containing these standards
for inter-process communications across the Internet "web services". They include
XML based protocols such as Simple Object Access Protocol (SOAP), and Web Services
Description Language (WSDL), and Universal Description, Discovery, and Integration
(UDDI). It is true that SOAP's inception started with The Borg, in addition to
IBM and Ariba. Yet, when it was submitted to the World Wide Web Consortium's open
standards process, and upon review we concluded there was nothing in there that
gave Windows a distinct advantage, or Microsoft in general, it quickly gained
acceptance even before being declared an official standard. SOAP is the primary
protocol for implementing web services. This XML based standard permits a consumer
to utilize the services of a web services provider. In short, this is a simplified
XML version of COM, CORBA or EJB, only without the specific requirement of a "component",
"object", or "bean", or anything except... well... a "web service". While all
the other web service standards have their place, SOAP is the only one that is
essential for the consumption of a web service. It is possible to create a simple
service and a simple consumer using nothing but SOAP, leaving out UDDI and other
overhead. What's the difference between web services, and COM, CORBA and EJB?
You are not likely to get a straight answer from the owners of the earlier technologies,
because doing so would be tantamount to admiting that they should have begun by
agreeing on open standards in the first place. The important thing is web services
is different; and the real important thing is that, for the first time in history,
all the IT giants in the industry appear to agree. Now we can finally begin large
scale distributed computing. Let's just start wrapping our COM, CORBA, and EBJ
objects in pretty little web services packaging, and pretend like the last decade
of bickering didn't really happen. UDDI, currently managed by UDDI.org, promises
to increase both the value and rate of growth of web services by enabling a more
structured version of what one can think of as a "web search for web services."
By allowing providers to submit descriptions of their offerings, and allowing
consumers to locate all the various web services available for a particular need,
UDDI promises to increase the benefits for both sides of the equation. Currently,
Microsoft, HP, SAP and IBM all manage UDDI Registries. It is worth noting that
Microsoft originally had something called DISCO that does what UDDI does. However,
when it became clear that UDDI was already popular, Microsoft replaced their proprietary
DISCO with its open standard counterpart. Let's give thanks, once again, that
disco is dead! WSDL does not appear to be an offical open standard, yet, as it
has only been submitted to and accepted by the W3C
as a "note", meaning that no one other than Microsoft, IBM and Ariba appear
to have worked on it. Don't tell every else, though, lest you ruin the web services
celebration. For all intensive purposes, it is being endorsed as a standard for
describing in a highly technical and structured way how a consumer of a web service
can access all of a services' parts, or at least that was my take on all the jargon
I read about ports, end points, bindings, messages, operations and french fries.
OK, maybe it didn't mention french fries; but, by the time you are done reading
it all, the one realization that will come to you is that you are probably ready
to eat again. The W3C has a working group called the XML Protocol (XMLP), which
builds upon SOAP to offer standards for implementing SOAP in many different communications
contexts. In trying to be all things to all people, XMLP is committed to being
independent of both programming model and mode of communications between peers.
It is likely to define at a higher level than the original SOAP submission how
our web applications will talk to each other, creating an XML based foundation
upon which we can build, at a distributed level, traditional development concepts
such as even-driven, state-transition and multi-threading programming models.
Why did Microsoft concede the inevitable so quickly and openly and bluntly, not
only giving in to, but helping to foster the open standards, when they have such
a history of fighting tooth and nail for every inch of Internet space? I suspect
that, like the Internet in the past, an offense with strong marketing can once
again hide the fact that Microsoft faces its greatest threat. With all eyes on
Bill's offensive .NET team, who would notice they were really on the defense?
Instead of openly opposing the enemy, Microsoft has chosen to embrace it, hug
it, love it dearly, for the world to see. How, with all that affection, can the
Internet possibly be a threat to Microsoft? Thus, .NET and the open distributed
computing protocols that enable web services are being sold like a marriage made
in heaven. To be sure, despite the Internet, growing global unity on open standards,
and the promise of distributed computing on a scale never before seen in the age
of computers, all hope is not lost for Microsoft. The theory that Microsoft has
chosen to prove is that the individual machine, and its intangible components
(software objects), will still have value in this new world where interconnectivity
is essential. Instead of arguing about how the world's components will connect,
Microsoft is seeking to prove that it can help to produce the best components
at the lowest cost. This is where .NET enters the picture. This is the new sexy
machinery Microsoft is showing off as the primary contender in the oncoming web
services war. With all its marketing might, Microsoft is betting the house on
this new architecture. After all, the only other option is to become irrelevant
in a world where a computer will no longer be considered "booted up" until it
is connected. Microsoft is not alone on the playing field. It has Sun to contend
with. Of course, Sun isn't just a company, but the representative of every J2EE
vendor and Java user out there. Together, they are a force to be reckoned with.
Heavyweights like IBM, whose annual revenues Microsoft still dreams of approaching,
have made J2EE the center of their applications initiatives. Oracle, BEA, HP and
countless others are pooling their efforts together. And, let's not forget various
open source organizations, from Apache to JBoss, like grass roots operations,
they promise to pluck Microsoft from the hearts of countless individual devotees.
Is Sun late to the web services game, as some have said? To this I say what game?
It is clear there will be a game, but it is not clear that the game has really
gone past the kick off. The reality is, a shift like this can take years to evolve.
Web services are poised to grow far more in 2004 than they will in this year,
the year of their illumination. So far, all we see is a lot of gossip, and very
few real life stories. The vast majority of the enterprises that will use web
services have yet to make a commitment to the specific means of how they will
leverage this new technology. Indeed, most are still pondering how they can benefit
from it. If you compare Sun to Microsoft, one can debate who was first to enter
the web services arena. Yet, if you compare them both to the market they are hoping
to appeal to, they are either early, or just in time. Nobody is late. Is it true
that Sun's roadmap is unclear? This has to be viewed from two perspectives. From
a technical viewpoint, we are primarily talking about the ability to take business
processes, and expose them via open standards protocols over the Internet. Does
Sun have a library for doing this? Yes, it does. You can download it freely today,
and begin anytime you like to create your first web services. Is it better than
.NET? This I cannot answer, since I have yet to use either one. However, the question
I have is whether or not the Java community, with its large base, corporate support
and open source initiatives, can produce a better framework over the next year
or so. This seems more important than who was first, since I suspect a year or
two is a better time frame for when web services is likely to really be revved
up on a large scale. The second perspective the roadmap question has to be considered
with is in the area of business. Web services is about more than just distributed
computing. To a business, it is about creating and consuming new services, or
utilizing old services in an improved way. The question each business must ask
is how can they best leverage this new ability to either create new services for
the market, or consume web services in a way that increases their competitiveness
and improves their bottom line. Can Sun or Microsoft really answer this question
for all the businesses out there? Is there a map that any one company can provide?
The truth is, the hardest road to identify is not the technical path, but the
business opportunities. If there is a delay in this game, it is to give pause
to consider everyone's options. It is the great huddle of corporate decision makers
assessing how the next play can help them win the game. To this, I submit, silence
from Microsoft and Sun will do more good. It is not their job to run everyone's
businesses. To return to our original question, is the whole "web services" thing
hype? Web services is at least a solid beginning to a new era of distributed computing
that is as inevitable as paved roads. If web services is not hype, what remains
to be questioned are the tools and services the hype masters themselves know you
do not have to choose. Will .NET be the answer for everyone? Will Java take the
lead through its community involvement and open source support? Will supply and
demand for web services skyrocket in the next few months? These are things to
be hyped. Will web services and distributed computing change our lives? Now I
hear a ring of truth.

RDF - the XML format for metadata - essentially describes relationships between resources and is a superset of the problem area you describe. I had a cursory look to see if people had taken the obvious step of using diagram tools to edit rdf and yes they have:

Using DIA and GraMToR and GraphViz and IsaViz and lots lots more

You might also be interested in They Rule which draws some interesting social networks!

While this is all standard 2d editing (I think the 3d editing thing is nonsense btw, unless you actually have a 3d coordinate system then you are actually describing a 2d network diagram) there are other visualisation options which may be interesting. Mindmapping tools allow you to navigate the network of concepts may be interesting as are star trees. Both provide a focussed view on a small part of a much larger network with some context information to help you choose how to navigate. They are more useful for display than authoring.

Hope something in here is useful

-Baz

RDF - the XML format for metadata - essentially describes relationships between resources and is a superset of the problem area you describe. I had a cursory look to see if people had taken the obvious step of using diagram tools to edit rdf and yes they have:

Using DIA and GraMToR and GraphViz and IsaViz and lots lots more

You might also be interested in They Rule which draws some interesting social networks!

While this is all standard 2d editing (I think the 3d editing thing is nonsense btw, unless you actually have a 3d coordinate system then you are actually describing a 2d network diagram) there are other visualisation options which may be interesting. Mindmapping tools allow you to navigate the network of concepts may be interesting as are star trees. Both provide a focussed view on a small part of a much larger network with some context information to help you choose how to navigate. They are more useful for display than authoring.

Hope something in here is useful

-Baz

RDF - the XML format for metadata - essentially describes relationships between resources and is a superset of the problem area you describe. I had a cursory look to see if people had taken the obvious step of using diagram tools to edit rdf and yes they have:

Using DIA and GraMToR and GraphViz and IsaViz and lots lots more

You might also be interested in They Rule which draws some interesting social networks!

While this is all standard 2d editing (I think the 3d editing thing is nonsense btw, unless you actually have a 3d coordinate system then you are actually describing a 2d network diagram) there are other visualisation options which may be interesting. Mindmapping tools allow you to navigate the network of concepts may be interesting as are star trees. Both provide a focussed view on a small part of a much larger network with some context information to help you choose how to navigate. They are more useful for display than authoring.

Hope something in here is useful

-Baz

RDF - the XML format for metadata - essentially describes relationships between resources and is a superset of the problem area you describe. I had a cursory look to see if people had taken the obvious step of using diagram tools to edit rdf and yes they have:

Using DIA and GraMToR and GraphViz and IsaViz and lots lots more

You might also be interested in They Rule which draws some interesting social networks!

While this is all standard 2d editing (I think the 3d editing thing is nonsense btw, unless you actually have a 3d coordinate system then you are actually describing a 2d network diagram) there are other visualisation options which may be interesting. Mindmapping tools allow you to navigate the network of concepts may be interesting as are star trees. Both provide a focussed view on a small part of a much larger network with some context information to help you choose how to navigate. They are more useful for display than authoring.

Hope something in here is useful

-Baz

On the other hand, ads are dead. What good are ads anyway? They only make pages load slower, waste bandwidth, and most importantly, they make the products I would buy anyway more expensive. So rather than pay another 1 buck (of whatever currency) for a product, I'd rather pay that 1 buck directly. If you would let me do it.

I think we are going to see some nasty situations soon. Obviously, banner ads are going to fail miserably soon. Ad-filtering software is being implemented in browsers, people are starting to really hate them. Joe Sixpack too. As a response, I think we might see more attempts to force you to look at them.

Content providers gotta eat too. They need the money. We ads failing, we are going to see more and more closed models, and the big content industry will lobby bad laws through that may go a long way in making sure it will be very difficult for independent journalism to get exposure. I don't know how exactly this is going to be, but then, I really couldn't imagine how bad DMCA was going to be. Given the track record I would say, be very afraid.

So, I think that to save free speech, we, the free software and open source communities have to start developing stuff to facilitate a move away from free as in beer. We must abandon free beer to get free speech.

This is how I would pay for Slashdot:

When I surfed on Slashdot, the browser recorded what I did, and along with it, payment information, inserted not only by /. editors, but also those who made comments. This payment information would include what /. editors would think a story should cost. Say once a week, I would review the stuff I had surfed, and authorize payments. Some money would go to /. for their editorial efforts, for hardware, etc. Some money would even go to posters of comments I would find insightful.

There would have to be short path between me, making payments, and receivers of payments, so banks would have to get involved, and they would have to rethink many things, and realize it doesn't cost that much to perform simple database queries.

In fact, this would not only apply to Slashdot, I would like to pay pretty much every newspaper and journal I read online this way. Also, I'd like to be paid for the content I provide myself this way. It should be big.

It requires involvement from many parties, and we really should have standards. Unfortunately, W3C's E-commerce activity died a horrible death. A good start would be implementation in browsers, and we can do that. After all, if we make something that works, and we're actually making money this way, they ought to come running. Making money by having a shortest possible path between end-users and content providers should be attractive to everyone.

* Linux system administrators are filthy hippies who are more interested in SOAP than soap .
and
* According to the terms of the GPL, if you use Linux in a production environment you are no longer allowed to charge for your company's services.

I have always found it strange that people in the computer industry tend to be some of the most backwards when it comes to exploiting technology.

This

<font FACE="COURIER NEW" SIZE="-2"><b><i>Arcade Machine Emulators for download...</i></b></font>

is not new technology. It's actually very outdated way to control text appearance. If you want to exploit technology, use XHTML Strict and Cascading Style Sheets.

But I wasn't talking about the way how the fonts are made smaller than the default size (size="+1" is the font larger than the user default and size="-2" is font smaller than the user default font, i.e. this size which I find the most readable - see my web design rules if you're not sure what I mean). I was only commenting the idea of using fonts smaller than the size which I have chosen as the best size for me.

Incidentally, you can zoom in to view the text better using menu options, or in IE you can hold down the control key and use the mouse wheel.

Of course I can set my default font so large that when the size is decreased twice the result will be my favorite size. But this way the correctly designed websites would have fonts too large and it's completely backwards and doesn't make much sense.

I'm sorry if you found my comment offensive. I was mostly joking because I visited a website with tiny games and I found the fonts so tiny that I couldn't read anything, which kind of made sense, because people who play so tiny games obviously has to have great sight, unlike myself. The first thing I thought was that you may have set the fonts so small, so the people with poor sight (those who wouldn't be able to play those games anyway), won't waste your bandwidth downloading games to small for them to play, because they won't find the download links. I found that kind of funny.

As for the Javascript, as I said (please read my comment), I couldn't see the screenshots even after I enabled Javascript, so something is just broken. (JavaScript Error: http://www.tinywindowsgames.com/tiny/: document.all has no properties.)

Most people have JavaScript enabled and that helps us to create sites in a quick and useful way.

Yes, most of people, but not everyone. Unless you use the <noscript> tag, you have to understand that those who don't have Javascript enabled, or those who don't use Javascript browsers at all, will complain that your website simply don't work, which is true however great working with Javascript it may be.

Just use <noscript> tag and your website will work great for everyone. People with working Javascript interpreters won't see <noscript>this code</noscript> at all, so your site will be exactly the same for those who can use it today. The only difference will be to those people who can't use it today. Please read my web design rules, I believe you'll find quite a few good points there.

I'm glad that you answered and I'm honored that you probably made your account just to answer my comment. The main reason I posted my comment (other than a joke about tiny games and tiny fonts correlation) was to ask if these games are available only for Windows, because I don't have Windows (I use Debian) but I'd like to check them out. So please tell me: what platforms do you support? Are those games released as free software (in the FSF sense)?

If your games work under GNU/Linux systems, then I'll be glad to check them out. If they are written only for Windows but they are released as free software, then I'll maybe try to port some of them when I find any time for that. Please tell me where I can find the working screenshots, I'd like to see how do these games look like in the first place.

Thanks and, once again, I'm sorry if you misunderstood my intentions, I really didn't want to offend you. Please don't confuse my post with the somehow more offensive parent post by limbostar.

I have always found it strange that people in the computer industry tend to be some of the most backwards when it comes to exploiting technology.

This

<font FACE="COURIER NEW" SIZE="-2"><b><i>Arcade Machine Emulators for download...</i></b></font>

is not new technology. It's actually very outdated way to control text appearance. If you want to exploit technology, use XHTML Strict and Cascading Style Sheets.

But I wasn't talking about the way how the fonts are made smaller than the default size (size="+1" is the font larger than the user default and size="-2" is font smaller than the user default font, i.e. this size which I find the most readable - see my web design rules if you're not sure what I mean). I was only commenting the idea of using fonts smaller than the size which I have chosen as the best size for me.

Incidentally, you can zoom in to view the text better using menu options, or in IE you can hold down the control key and use the mouse wheel.

Of course I can set my default font so large that when the size is decreased twice the result will be my favorite size. But this way the correctly designed websites would have fonts too large and it's completely backwards and doesn't make much sense.

I'm sorry if you found my comment offensive. I was mostly joking because I visited a website with tiny games and I found the fonts so tiny that I couldn't read anything, which kind of made sense, because people who play so tiny games obviously has to have great sight, unlike myself. The first thing I thought was that you may have set the fonts so small, so the people with poor sight (those who wouldn't be able to play those games anyway), won't waste your bandwidth downloading games to small for them to play, because they won't find the download links. I found that kind of funny.

As for the Javascript, as I said (please read my comment), I couldn't see the screenshots even after I enabled Javascript, so something is just broken. (JavaScript Error: http://www.tinywindowsgames.com/tiny/: document.all has no properties.)

Most people have JavaScript enabled and that helps us to create sites in a quick and useful way.

Yes, most of people, but not everyone. Unless you use the <noscript> tag, you have to understand that those who don't have Javascript enabled, or those who don't use Javascript browsers at all, will complain that your website simply don't work, which is true however great working with Javascript it may be.

Just use <noscript> tag and your website will work great for everyone. People with working Javascript interpreters won't see <noscript>this code</noscript> at all, so your site will be exactly the same for those who can use it today. The only difference will be to those people who can't use it today. Please read my web design rules, I believe you'll find quite a few good points there.

I'm glad that you answered and I'm honored that you probably made your account just to answer my comment. The main reason I posted my comment (other than a joke about tiny games and tiny fonts correlation) was to ask if these games are available only for Windows, because I don't have Windows (I use Debian) but I'd like to check them out. So please tell me: what platforms do you support? Are those games released as free software (in the FSF sense)?

If your games work under GNU/Linux systems, then I'll be glad to check them out. If they are written only for Windows but they are released as free software, then I'll maybe try to port some of them when I find any time for that. Please tell me where I can find the working screenshots, I'd like to see how do these games look like in the first place.

Thanks and, once again, I'm sorry if you misunderstood my intentions, I really didn't want to offend you. Please don't confuse my post with the somehow more offensive parent post by limbostar.

Your server should send pictures in a format that the browser says he understands - if you haven't found out yet, every time a browser asks for something from your webserver, it sends a list of formats it understands, including picture formats.

Even if the msie-crash.txt file was named msie-crash.html but there was "Content-Type: text/plain" in HTTP response headers it should be displayed as plain text, and in fact I was sure that this IE bug is only present in exactly such a situations. I'm really surprised that if MIME type and file suffix (the main data type indicator in MS software) tell the IE that it's a plain text, it still tries to render it as HTML.

It's a very serious problem if you want to make an HTML tutorial website, having links such as: http://tutorial.host/example/foo.html and http://tutorial.host/source/foo.html where both foo.html are just symlinks to the same file but you set up your web server to send "Content-Type: text/html" under /example to show how it looks like and "Content-Type: text/plain" under /source to show the source.

Not to mention problems with sending different MIME type to force the download and saving of file instead of displaying it (try downloading a 100MB flat text database when your browser wants to display it first). It's a serious problem and making all of the workarounds can be often a real pain in the ass (like when you have to display HTML source, as HTML page including HTML source with s/</&lt;/g etc.) because 90% of "web browsers" out there can't even understand a damned Content-Type header, the most important HTTP response header, present in six years old HTTP 1.0 specification (and with the Web, six years are the whole ages), and I'm sure it was used in pre-RFC, pre-1.0 HTTP much earlier (if anyone knows, I'll be glad to hear about the real age of Content-Type header - thanks).

OK, I'm glad you touched this subject. For those who don't know about it, let me quote HTTP 1.0 from May 1996: "HTTP uses Internet Media Types in the Content-Type header field in order to provide open and extensible data typing." and HTTP 1.1 from June 1999: "HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation." It's not used without an important reason.

See also:

• RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies (June 1992)
• RFC 1945 - HTTP/1.0 (May 1996) Sections: 10.5 Content-Type, 7.2.1 Type, 3.6 Media Types
• RFC 2616 - HTTP/1.1 (June 1999) Sections: 14.17 Content-Type, 7.2.1 Type, 3.7 Media Types

Very serious bug, I wonder when are they planning to fix it.

Even if the msie-crash.txt file was named msie-crash.html but there was "Content-Type: text/plain" in HTTP response headers it should be displayed as plain text, and in fact I was sure that this IE bug is only present in exactly such a situations. I'm really surprised that if MIME type and file suffix (the main data type indicator in MS software) tell the IE that it's a plain text, it still tries to render it as HTML.

It's a very serious problem if you want to make an HTML tutorial website, having links such as: http://tutorial.host/example/foo.html and http://tutorial.host/source/foo.html where both foo.html are just symlinks to the same file but you set up your web server to send "Content-Type: text/html" under /example to show how it looks like and "Content-Type: text/plain" under /source to show the source.

Not to mention problems with sending different MIME type to force the download and saving of file instead of displaying it (try downloading a 100MB flat text database when your browser wants to display it first). It's a serious problem and making all of the workarounds can be often a real pain in the ass (like when you have to display HTML source, as HTML page including HTML source with s/</&lt;/g etc.) because 90% of "web browsers" out there can't even understand a damned Content-Type header, the most important HTTP response header, present in six years old HTTP 1.0 specification (and with the Web, six years are the whole ages), and I'm sure it was used in pre-RFC, pre-1.0 HTTP much earlier (if anyone knows, I'll be glad to hear about the real age of Content-Type header - thanks).

OK, I'm glad you touched this subject. For those who don't know about it, let me quote HTTP 1.0 from May 1996: "HTTP uses Internet Media Types in the Content-Type header field in order to provide open and extensible data typing." and HTTP 1.1 from June 1999: "HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation." It's not used without an important reason.

See also:

• RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies (June 1992)
• RFC 1945 - HTTP/1.0 (May 1996) Sections: 10.5 Content-Type, 7.2.1 Type, 3.6 Media Types
• RFC 2616 - HTTP/1.1 (June 1999) Sections: 14.17 Content-Type, 7.2.1 Type, 3.7 Media Types

Very serious bug, I wonder when are they planning to fix it.

Even if the msie-crash.txt file was named msie-crash.html but there was "Content-Type: text/plain" in HTTP response headers it should be displayed as plain text, and in fact I was sure that this IE bug is only present in exactly such a situations. I'm really surprised that if MIME type and file suffix (the main data type indicator in MS software) tell the IE that it's a plain text, it still tries to render it as HTML.

It's a very serious problem if you want to make an HTML tutorial website, having links such as: http://tutorial.host/example/foo.html and http://tutorial.host/source/foo.html where both foo.html are just symlinks to the same file but you set up your web server to send "Content-Type: text/html" under /example to show how it looks like and "Content-Type: text/plain" under /source to show the source.

Not to mention problems with sending different MIME type to force the download and saving of file instead of displaying it (try downloading a 100MB flat text database when your browser wants to display it first). It's a serious problem and making all of the workarounds can be often a real pain in the ass (like when you have to display HTML source, as HTML page including HTML source with s/</&lt;/g etc.) because 90% of "web browsers" out there can't even understand a damned Content-Type header, the most important HTTP response header, present in six years old HTTP 1.0 specification (and with the Web, six years are the whole ages), and I'm sure it was used in pre-RFC, pre-1.0 HTTP much earlier (if anyone knows, I'll be glad to hear about the real age of Content-Type header - thanks).

OK, I'm glad you touched this subject. For those who don't know about it, let me quote HTTP 1.0 from May 1996: "HTTP uses Internet Media Types in the Content-Type header field in order to provide open and extensible data typing." and HTTP 1.1 from June 1999: "HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation." It's not used without an important reason.

See also:

• RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies (June 1992)
• RFC 1945 - HTTP/1.0 (May 1996) Sections: 10.5 Content-Type, 7.2.1 Type, 3.6 Media Types
• RFC 2616 - HTTP/1.1 (June 1999) Sections: 14.17 Content-Type, 7.2.1 Type, 3.7 Media Types

Very serious bug, I wonder when are they planning to fix it.

He's been working on The Semantic Web.

All web browsers suck. I don't care which platform you're on.

It's 2002 now... and the web, moreovere, webbrowsers, have had over five years to mature. Yet there isn't a single browser out there that is a respectful mix of standards-based compatiblity, ease of use, and speed. Why?

Don't feed me that line that you can't have everything in one package because once you add-in all of the features, things must slow down. Phooey. We can get Quake to run @ 92837423947fps, but can't get a kickass browser in the market. WTF is *that* all about?

And looking upon the IE alternatives...

-Netscape 6.2? Get real. I would probably look upon it more favorably if it were coded to take advantage of Quartz/Aqua & Carbon/Cocoa in OSX. I'd also like to mention that its scrolling bar is *way* too narrow...

-OmniWeb? They want me to pay them ~$30 for an incomplete browser... yah right. Try fixing your java & CSS support, guys.

-Opera? You're kidding right? It's in the same class as Omni, if you ask me.

-IE? It has wronfully become the litimus test for web-development. Yet... is a necessary evil. The majority of browsers out there are IE. Why wouldn't your site be geared towards it? :(

I've said it before, and I'll say it again... the *ONLY* competition IE has is Netscape.

What really boggles my mind is that this likes to render in a variety of ways depending on which os, browser, and platform you use. That to me is just pathetic.

Stupid as this sounds... I'd rather build a webpage based on PDF. Then I'd at least know it would look the same no matter where it loaded. And would scale so it wouldn't be tethered to a set screen resolution.

But, you must supply the same information in an accessible format, and that is not Flash, especially for the audience your site will have. Go ahead and use Flash, but make sure you supply the same information in an accessible format. Navigation and interactivity must be usable from both keyboard and mouse. All the text must be readable by text readers. Users must be able to have the ability to stop the animation and be given an unlimited amount of time to interact with the information (e.g. automatic slideshow should have a "manual" option).

I don't know if you've taken all this into consideration, but here are some links that will help you address accessibility issues:

• W3C WAI: Web Accessibility Initiative
• Section 508: Government Accessibility Laws and Guidelines
• UseIt.com: Jakob Neilsen's Usability Site
• Usable Web: Links about Web Usability

I'm a geek. I think Flash rocks (I don't use it myself). Sometimes the browser I am using is not the latest greatest Mozilla/Netscape/IE/Opera -- it's Lynx.

What you describe here is already being done to some extent by the P3P Project. It is designed to give consumers a quick concise view of how a website's privacy policy matches up to their preferences. You fill out a survey stating what you look for in a website, both the good and the bad, then when you visit a website, you can view the differences with P3P. Check it out.

I'm personally hoping that it takes off.

The only way to really keep the kiddies safe from being accosted by big, bad breasts is to use a system on the child's computer which relies on a continually monitored whitelist of "safe" sites. Besides, breaking the system so they can look at boobies is good computer experience.

It doesn't even have the colours in hexadecimal (see here). Sorry, I'll just use the colour picker in Paint Shop Pro, it'll give out the colour in hex and I can easily cut and paste that value to my web pages. I guess I could use the RGB values as well, but I'm not used to using them yet :)

Somebody already did that. Standard protocols good, embrace and extend bad.

Anyway, I would choose SVG over flash any day.

The Mozilla SVG implementation is a native SVG implementation. This is as opposed to plug-in SVG viewers such as the Adobe viewer (which is currently the most popular SVG viewer).

Some of the implications of this are:

• Mozilla can handle documents that contain SVG, MathML, XHTML, XUL, etc. all mixed together in the same 'compound' document. This is being made possible by using XML namesspaces.
• Mozilla is 'aware' of the SVG content. It can be accessed through the SVG DOM (which is compatible with the XML DOM) and manipulated by Mozilla's script engine.
• Other Mozilla technologies can be used with SVG. XBL coupled with SVG is a particular interesting combination. It can be used to create graphical widgets (I wonder when we'll see the first SVG-based chrome!) or extend Mozilla to recognize other specialized languages such as e.g. CML (chemical markup language). There are samples of these kinds of more advanced usage patterns on croczilla.com/svg/.

The Mozilla SVG implementation is a native SVG implementation. This is as opposed to plug-in SVG viewers such as the Adobe viewer (which is currently the most popular SVG viewer).

Some of the implications of this are:

• Mozilla can handle documents that contain SVG, MathML, XHTML, XUL, etc. all mixed together in the same 'compound' document. This is being made possible by using XML namesspaces.
• Mozilla is 'aware' of the SVG content. It can be accessed through the SVG DOM (which is compatible with the XML DOM) and manipulated by Mozilla's script engine.
• Other Mozilla technologies can be used with SVG. XBL coupled with SVG is a particular interesting combination. It can be used to create graphical widgets (I wonder when we'll see the first SVG-based chrome!) or extend Mozilla to recognize other specialized languages such as e.g. CML (chemical markup language). There are samples of these kinds of more advanced usage patterns on croczilla.com/svg/.

As you can see here.

Even though the W3C has backed away from the proposal to include RAND-licenced patented material in W3C standards, the SVG standard went to 1.0 under the assumption that the public would accept RAND-licensing for web standards, and so SVG incorporates a number of RAND-liceneced patents, specifically from IBM Kodak and Quark. No doubt this situation is going to be resolved, especially if people don't forget it still needs to be resolved. To remind the W3C and the companies involved that this situation is still unresolved, you can comment on this list, subscribe here.

And oh by the way, is IBM's roll in this particular little minidrama hypocritical, given their support for and reliance upon Linux and other open source projects? You bet it is, and that's because IBM has lots of little parts, not all of which are headed in the same direction, e.g., some are run by the legal department or managers who still don't get it.

As you can see here.

Even though the W3C has backed away from the proposal to include RAND-licenced patented material in W3C standards, the SVG standard went to 1.0 under the assumption that the public would accept RAND-licensing for web standards, and so SVG incorporates a number of RAND-liceneced patents, specifically from IBM Kodak and Quark. No doubt this situation is going to be resolved, especially if people don't forget it still needs to be resolved. To remind the W3C and the companies involved that this situation is still unresolved, you can comment on this list, subscribe here.

And oh by the way, is IBM's roll in this particular little minidrama hypocritical, given their support for and reliance upon Linux and other open source projects? You bet it is, and that's because IBM has lots of little parts, not all of which are headed in the same direction, e.g., some are run by the legal department or managers who still don't get it.

As you can see here.

Even though the W3C has backed away from the proposal to include RAND-licenced patented material in W3C standards, the SVG standard went to 1.0 under the assumption that the public would accept RAND-licensing for web standards, and so SVG incorporates a number of RAND-liceneced patents, specifically from IBM Kodak and Quark. No doubt this situation is going to be resolved, especially if people don't forget it still needs to be resolved. To remind the W3C and the companies involved that this situation is still unresolved, you can comment on this list, subscribe here.

And oh by the way, is IBM's roll in this particular little minidrama hypocritical, given their support for and reliance upon Linux and other open source projects? You bet it is, and that's because IBM has lots of little parts, not all of which are headed in the same direction, e.g., some are run by the legal department or managers who still don't get it.

Amongst other things, I develop site backends with Macromedia (formerly Allaire) ColdFusion. Several months ago, I needed to add a dynamic (and interactive) Gantt chart to a client's site.

My options were Flash, SVG, or Java. At first glance, SVG was the least appealing choice: I know Java, and Macromedia has several applications which allow for ColdFusion-Flash development. Yet when I looked at the development time for a Java applet as well as the cost, poor documentation and kludgey implementation of a CF-Flash workaround from Macromedia, SVG came out on top. And the price couldn't be beat.

Within a day I had ColdFusion to dynamically generating the SVG chart from data in SQL Server 2000. I had nice crisp lines, vibrant color, mouseovers and interactive features.

As other posters have said, Flash isn't an awful choice -- but it has been primarily used for fluff.

How about a nice alternative to Flash.

• The plugin
• A cool example of SVG.

The W3C SVG page may be found here. Probably the most popular browser plug-in is made by Adobe and you can get it here (RedHat 7.1 and Solaris 8 versions of the plug-in are somewhat hard to find but are still available).

You might also wish to check out some of Adobe's demos. Jasc has a Win32 app called WebDraw that can come in handy, too.

Or an in-browser app that automatically Google-linked everything in a page? Like M$'s proposed auto-linking, but populist. True hypertext.

Good luck! Don't count on feeling lucky d;-)

Microsoft is at it again, this time big-blue is right along with them. IBM and Microsoft are trying to erect so-called standard-bodies that would allow them to get-around the World Wide Web Consortium (W3C) requirements for standards to be royalty-free.
Read this article over at ZDNet to get an overview of what is going on.

While they did release the core SOAP and UDDI specifications to the royalty-free process, they are trying to create "piggy-back" protocls that will ensue royalties (i.e. security signing of SOAP messages, file attachments on soap messages and security policy negotiations). They are trying to establish these standards through the UDDI and WS-I organizations. These organizations are perceived to be open and acceptable standard bodies, but they are not. They are heavily controlled by both juggernauts and conform to their interests.

The W3C and the IETF are the only true standard bodies of the Internet! Do not be fooled by IBM and Microsoft and do not be sucked into their grip!
They are trying to ensure that Open-Source, Free implementations of these standards will not be possible! They will be trying to become "toll-boothes" on the Internet.

Microsoft is at it again, this time big-blue is right along with them. IBM and Microsoft are trying to erect so-called standard-bodies that would allow them to get-around the World Wide Web Consortium (W3C) requirements for standards to be royalty-free.
Read this article over at ZDNet to get an overview of what is going on.

While they did release the core SOAP and UDDI specifications to the royalty-free process, they are trying to create "piggy-back" protocls that will ensue royalties (i.e. security signing of SOAP messages, file attachments on soap messages and security policy negotiations). They are trying to establish these standards through the UDDI and WS-I organizations. These organizations are perceived to be open and acceptable standard bodies, but they are not. They are heavily controlled by both juggernauts and conform to their interests.

The W3C and the IETF are the only true standard bodies of the Internet! Do not be fooled by IBM and Microsoft and do not be sucked into their grip!
They are trying to ensure that Open-Source, Free implementations of these standards will not be possible! They will be trying to become "toll-boothes" on the Internet.

The fucking potential for the fucking two giants to fuckin' erect a goddamn toll booth is tied to the fucking likelihood that Web services protocols such as SOAP, WSDL, and UDDI--and the fucking related ones to fuckin' which the fucking two companies hold patents or other intellectual property rights-- will one day be as important as the fucking standard protocols (such as TCP/IP and HTTP) on which the fucking Internet is based today. You are a pussy. Web services and the fucking protocols that make them piece of shits possible are destined to play a motherfucking major role in most if not all electronic commerce as well as other Internet traffic.

If the fucking protocols do become standards, either by virtue of a fuckin' independent standards organization's imprimatur or by attaining a de facto status, IBM and Microsoft--or any other company that maintains the fucking intellectual property rights to their sorry ass--could legally impose royalties on that traffic. In fact, any protocols that become a part of the fucking core Internet infrastructure without having been made available on a fuckin' royalty-free basis could guarantee the fucking owners of the fucking intellectual property the fucking right to fuckin' place a fuckin' tax on the fucking Internet traffic that depends on those protocols. I will eat your soul.

No motherfucking standard policy
For the fucking most part, standards-setting for the fucking Internet and Web has taken place within the fucking working groups of two organizations: the fucking Internet Engineering Task Force (IETF) and the fucking World Wide Web Consortium (W3C). You are a shithole. Until recently, neither organization had maintained a policy requiring vendors to make the fucking intellectual property (IP) them poo pirates contribute to the fucking standards setting process available on a royalty-free basis. Know this, you are a fuck. According to W3C Patent Policy Working Group Chairman Danny Weitzner, "Despite the fucking lack of a policy, there has always been a goddamn understanding amongst the fucking various contributors that the fucking Internet and the fucking Web wouldn't be possible or scalable unless their contributions were available to fuckin' all fuckheads on a royalty-free basis."

But that gentleman's agreement has been tested several times over the fucking years and that bastard could end up being tested again by Microsoft and IBM. According to fuckin' documents on the fucking W3C's Web site, IBM and Microsoft not only own intellectual property within specific Web services protocols, but also (in addition to the fact that you're a shit) have no motherfucking intentions of relinquishing their IP rights to those protocols should them horse lips become standards. Fact: you are a cock. The fucking documents indicate that the fucking two companies are currently maintaining their rights to pursue a fuckin' reasonable and non-discriminatory (RAND) licensing framework as opposed to a royalty-free-based framework. Pop Quiz, why are you such a fuckhead? The fucking RAND framework is widely acknowledged as the fucking one that keeps a motherfucking vendor's options open in terms of being able to charge content developers and Internet users a royalty for usage of relevant intellectual property.

> Good Web Developers hit up w3.org's validators for testing compliance.

I don't know, that thing is awefully picky. It doesn't even validate with the Mozilla web site (although it is possible). Are the Mozilla developers bad at web development? Perhaps. More acurately, I think a good web site doesn't necessarily have to follow all the W3C standards (although it is nice, I suppose).

I've seen countless web sites that display very well in Mozilla that get torn apart by the validator. I know, by ensuring W3C compiance you can be sure it will work in almost all browsers, but I don't necessarily care. I only worry about Mozilla and Internet Explorer. (Sorry Opera users, but it's bad enough dealing with two browsers on 3 different operating systems.)

I guess that's not why I'm not a web development professional...

> Good Web Developers hit up w3.org's validators for testing compliance.

I don't know, that thing is awefully picky. It doesn't even validate with the Mozilla web site (although it is possible). Are the Mozilla developers bad at web development? Perhaps. More acurately, I think a good web site doesn't necessarily have to follow all the W3C standards (although it is nice, I suppose).

I've seen countless web sites that display very well in Mozilla that get torn apart by the validator. I know, by ensuring W3C compiance you can be sure it will work in almost all browsers, but I don't necessarily care. I only worry about Mozilla and Internet Explorer. (Sorry Opera users, but it's bad enough dealing with two browsers on 3 different operating systems.)

I guess that's not why I'm not a web development professional...

Oh, !@#$. That should be validate. I hate screwing up URLs.

Sorry, but they did not invent XML or SOAP ... SOAP is a bloated enhancement of XML-RPC.

Ah, but Microsoft was not only involved in creating SOAP, but XML-RPC as well:

• Dave Winer discusses the history of XML-RPC, which was jointly designed by Userland Software, Microsoft and DevelopMentor
• SOAP specification at W3C. Note the employers of the authors. Lotus and IBM signed on at the last minute.

That's why the tags in the core HTML describe content like <em&gt indicates that the text should be displayed with emphasis as opposed to the newer <i> tag that does something similar. HTML marks content with rendering hints, but it's not designed to be able to lay out a page. It's designed to describe rendering hints on a page. Any time HTML is used to lay out a page, it's using a bastardization of tables and using tags that have been removed in HTML 4.01 strict (and are merely deprecated in HTML 4.01 transitional).

CSS (Cascading Style Sheets) is designed to lay out a page. CSS can be applied directly to an XML document (in the spec, maybe not via any tools yet), and it can also describe the page layout. I'd point you to my website that uses CSS to lay out the page, but it's currently offline, so I'll just have to send you to the W3 CSS site. If you're using a CSS compliant browser (Mozilla is the best at rendering it properly but IE works - dunno about anything else), you should notice the menu and the various links scattered about the top of the page that are defined via CSS page lay out rules.

HTML as originally designed is intended to describe sections of a document. At some point, people started developing fancy webpages and HTML 3 was born which included a lot of page lay out tags. However, more recently, with IE 5 and Mozilla, CSS and HTML have taken over for page design, meaning that newer sites can be designed using HTML 4.01 strict with CSS describing how it should be displayed. (This is the preferred, "proper" method.) Historically, HTML was originally designed to define a page structure, delinating paragraphs and lists. With HTML 4.01 it returns to the ideal, while using CSS to allow for fancy page layout.

However, I just don't see most website owners risking their livelihoods by implementing an image format which most of their customers, plugins or no, may not be able to read--particularly since so much of web layout is done using images these days instead of text.

Oh, whatEVER! Like you, me, and everyone else doesn't run across Flash-only sites that are just for driver downloads from hardware manufacturers.

If you're basing your livelihood around something as sketchy as the internet (and you're not a pr0n pusher, which are the only people making money off of the net) then you're probably already having worse troubles.

Think about it--how many users are set to automatically download plugins as needed?

Every enduser that doesn't change the default setting in Internet Exploder for Windorks.

It's a risk most companies won't take--you don't want your users not being able to use your site.

OMG, that's the best laugh I've had off /. in a loooooooooooooong time. Try running most companies sites through http://validator.w3.org. Better yet, validate Slashdot, because it's obvious the webmasters here didn't. The only way you assure that all users can access your site is through strict HTML 4.01, and most companies could give a crap if you access their site or not, because as mentioned, they don't make any money on the web!

BZZZZZTT.

PNG supports 256 [palettes] like GIF, and also supports full 24bit colour [...] I'm not sure if PNG supports an alpha channels at 24 bit.

Er. Yes, my language was a bit too compact, wasn't it? Technically, PNG supports three pixel type representations: indexed, truecolor, and grayscale. Strictly speaking, truecolor pixels can be composed of 8-bit ["full 24-bit color"] or 16-bit ["fuller(?) 48-bit color"] samples. And yes, alpha transparency is supported *only* for truecolor and grayscale types, not indexed types. Images using the indexed pixel type must resort to "simple" transparency to emulate a "real" alpha channel, however.

Recommended reading: W3C PNG Recommendation.