Who said that the question was about setting up Java? The issue is that though the JDK is available it is incomplete and there are hence issues running Tomcat.
The question, though misworded, is about setting up Tomcat on FreeBSD which is nontrivial as the JDK is not 100% complete for this platform. As I understand it, many java applications need modification to get them running properly on FreeBSD, even though they may work perfectly well on Linux, Windows and Solaris.
Hopefully Sun will start to release official JDK/JREs for this platform very soon.
Why I wasn't using Java 10 years ago
on
C
·
· Score: 2, Funny
Because it only came out in 1995.
Also, old does not necessarily mean bad; universities still teach LISP (out in 1958) and quite rightly so.
Neither too dangerous nor tremendously cool.
on
Java RMI
·
· Score: 1
I think raising the performance problem is splitting hairs - the fact that the syntax is the same for both remote and local calls is more handy than dangerous IMHO.
I agree though that such syntactic sugar should be taken with a pinch of salt! The overstatement of the virtues of transparency leads many developers to believe that they REQUIRE transparency in everything, leads to (for example) lots of time wasted in writing persistence layers, O/R mappings and so forth whilst waiting for JDO to be released.
Good to see that not everyone's waxing lyrical about XML, EJB and SOAP these days. I agree that it's important to keep up with old technologies as well as new - the computer industry does have a terrible habit of "forgetting" really important technologies.
I am still waiting for a Common Lisp revival - many abusers of XML/XSL will kick themselves.
It looks worth a second look, but are there any articles which explain the concept in a more clear and objective manner? I have been to the aspectj site, parc/aop and aosd sites, to no avail - the articles seem a little more intent on selling the concepts rather than explaining them.
I dunno, but my mental buzzword filter kicks in reading articles like this. Or perhaps I am getting slow in my old age...
My main worry these days with new technologies is that many organisations and developers use them for namesake rather than practicality - they create a vicious circle where the job market becomes disproportionately biased in favour of technologies that are used less often but considered to be "important". EJB & XML spring to mind here - not that they are necessarily bad technologies, just that they are often over-applied just as a point-scoring exercise. And in many companies (not mine), employees are effectively rewarded for spending their time at work reading up on new technologies so that they can b.s. about them... generally leading to a bad work ethic centred around buzzwords rather than objectivity. Not that it bothers me, they are welcome to their inefficiency!
So, any links to more informative sites would be helpful, particularly one describing how it can improve productivity, quality, decrease development costs, or indeed, if it does not and why.... so far I am curious but unimpressed!
There is a fine line between being sceptical about a technology and denigrating it. Looking at the Cocoon site, it is an interesting technology but scepticism is quite understandable. The main reason for this is that it seems to be targeted at XML fans rather than giving clear business benefits. Compare with Sun's servlet site. Basically, from a business perspective, I see the following benefits, roughly in this order:
Servlets are supported by many vendors - so if one implementation sucks, the others may not. Also, if one J2EE vendor goes bust & all their source code catches fire, my servlets will run on another engine.
Servlets are a light framework - offering full unrestricted access to the Java API
Servlets can be written by anybody who knows Java - so if I need to, I can hire servlet-programmers very easily (almost everybody in my developer network knows Java and has written servlets before)
There is a large community of servlet developers - evidence that it is a sound technology
As someone who actually develops too, servlets *are* a sound technology!
Now it may be true that other frameworks offer these benefits, plus others - but they really ought to promote them. As I have posted many times before, I have been there, done that with many frameworks and abstraction and XML-related technologies and got p***ed off with them and gone back to old-fashioned Java/Tomcat/RDBMS - what makes this particular technology any better? Perhaps the fact that it is written by the same organisation who make Tomcat (and indeed it can run under Tomcat) is a good indicator, but they really should make more of that!
You seem to do a good job of promoting Cocoon - perhaps (seriously) you could talk to Apache & be their spokesperson.... Perhaps they could include it as a sample app with Tomcat? But by the looks of things, it is an unfinished symphony, that few people use. Unless there is a compelling reason to, I simply cannot afford to take the risk of tying myself into this. Not a denigration, but a sound business decision!
As for "reinventing the wheel", it's a bad analogy. For example, I use many already-existing libraries for performing processing such as image manipulation, connection brokering etc. but they are just that - libraries, and not entire frameworks. Buying into a framework takes more consideration than using a toolkit- it is more like being given a wheel but having to take the chassis and engine too!
I may still download and evaluate Cocoon at some stage, and time permitting, as it looks interesting at least, but I would like to see the technology, and documentation, mature a little first to address my other concerns. Cocoon may be wonderful, but at the moment it inspires little confidence - hence the understandable Fear, Uncertainty, and Doubt.
You seem to have spent the day defending your favourite technology. Which is fair enough.
However, if you read my comments before making a summary judgement about my motives, you will see that they still stand.
The original poster was asking for a comparison between Cocoon and Zope. To introduce a third option - to forget them both and try JSP/Servlets/MySQL - is hardly a cardinal sin.
It is still true that there is little evidence that Cocoon offers significant advantage over JSP/Servlets. I run my own one-man business and cannot try every technology that comes out for myself. I have to rely on factors such as existing user portfolio, feature list and advantage over what I currently do to make it worth trying to do my next site in Cocoon or whatever. To date the neither the site list nor the stated advantages are that impressive. As I have said, I separate content, logic and style just fine using JSP/Java Servlet/Database.
Perhaps XML really is wonderful, but I find the mantras of XML such as separation of content/logic, language-independence etc. often achievable with less effort elsewhere; hence such mantras ruin the credibility of XML in my view. I have worked on XML-based projects and find that very often the XML side of things was really superfluous.
You say that Cocoon can handle JSPs - can it handle servlets too? Can it offer the full functionality of, say, Tomcat? There is nothing in the Cocoon overview that says this. Perhaps, if the full Java/Servlet tools were at my disposal with Cocoon (and the overview stated this), I may consider it, but just JSP support alone is not enough for my purposes. I have much Java/Servlet code that supports my web development.
At the end of the day I am not trying to start a flame war - claiming that I am "talking out of my ass" are just plain rude - I am trying to evaluate for myself, and contribute to the debate, as to how best to create web apps. I am still the most productive web developer I know (though not necessarily the best!) and attribute this productivity to my pared-down use of Tomcat/MySQL, and specialised skill in Java/SQL. To say that I, personally, have not found a need for Cocoon is just plain true. The original poster wanted opinions - so what is wrong with giving one?
I agree - scalability is overrated
on
Zope or Cocoon 2?
·
· Score: 2, Insightful
Vendors often claim that solutions are scalable as an excuse for their complexity. In reality for the amount of extra effort involved in using a given framework, plus the extra cost (for example, EJB servers cost thousands of pounds, except for JBOSS which makes fewer such claims anyway), you could hire another programmer to scale an application within the same timescale and budget.
In addition, the bottleneck for web applications is most often the data store - so using a faster server or a scalable database (e.g. oracle), and buying more HTTP servers, using connection pooling etc. is often solution enough without buying into a costly framework.
I think that there are many issues with scalability that are lost in the hype and not really addressed properly. For example, downward scalability is just as important: handling the simple cases with minimal hardware and development time is something that many.bombs missed out on. You look at most successful websites and find that they started out as a hack with little regard for scalability. Getting the job done in the first place is more important than predicting how the site will cope with 1000 users per minute!
I don't want to rant for too long, but for my part, I have tried EJB and O/R wrappers and find them overrated and really miss the mark in many ways. If by scalability we mean "performing well under load", there is little substitute for well-written SQL and a fast DB server. Again, the "cacheing" claim of EJB etc. have yet to be substantiated.
My final two pence to anybody building a site is to design around a database schema and work "backwards" to find the appropriate supporting framework. This way, I can switch between Java, Python, Perl and whatever (even use them simultaneously) and my site data - the most important thing - will not be invalidated. On the other hand, I have found that basing the site around a particular framework is a recipe for vendor/language lock-in.
What the choice is between
on
Zope or Cocoon 2?
·
· Score: 2, Insightful
I am currently looking into a similar project myself but am considering the roll-your-own JSP/Servlet/Mysql against Zope. I have little evidence that Cocoon is a viable framework, much of the talk surrounding it seems like XML rhetoric.
At the end of the day my trade-off is one of flexibility versus ease. With Zope it is possible to hit the ground running, and it is usable to a large extent by non-programmers (in short, potentially less expensive to maintain a site). With the Java JSP/Servlets/MySQL, the sky is the limit, you have little "framework" as such to box you in, though you do have to work hard for it. Having said that, I am still going with the Java approach for the moment - a reasonable content-management site only takes around a week or two to do from the ground up, once you get the hang of it.
As for seperating content from style, I put the data in a database, use JSP templates designed by a HTML designer, and Java code. I have not really found a need for something like Cocoon at all as yet - with Java we have so many tools at our disposal to begin with.
Cheers for the advice - I have literally in the last half hour downloaded Zope for the first time ever, installed it, installed Squishdot and created a test site.
For all the talk of many other CMS I have yet to see anything as instantly usable as this. Perhaps I will reach the limit of this as I do with many other frameworks, but it's looking good so far for what I want to acheive....
I've been hearing a lot of good things about Zope and am considering giving it a try; I would be interested to hear some real-life case studies discussing any potential pitfalls with using Zope. I usually develop dynamic sites using servlets/JSP/Mysql as I generally like the flexibility I get, but this time I need to set up a prototype quickly (2-3 days) and pass on the development wholly to somebody who has only modest web development experience. Would Zope be useful in this situation, or would we hit brick walls too soon? The initial requirements are:
Bulletin boards with searching and querying
Dynamic news pages
User-definable home pages
Later on we would require e-commerce and so on. Any real-life developer experiences would be useful to hear of; I have had a look at a few sites that use Zope and they seem ok.
Freedom to choose?
on
FreeDOS
·
· Score: 2, Interesting
Open Source talks about freedom to use, but it also means freedom to choose. FreeDOS gives people another choice. If you don't want DOS, try something else
Does closed-source software not offer the same merits? I used DR DOS for a while too. PC-DOS also existed. Then there was GEM vs Windows, and later on we had OS/2. Let's not over-exaggerate the virtues of open-source - next we will be claiming, rightly but superflously, that it low in cholesterol!
Go and try it. Of course it cannot do your whole job for you, but a major step in understanding old code is to understand the class hierarchy. It is not a whole big app - you just run it on the code and it spits out HTML + diagrams. How can you say that it is useless if you have never used it and do not know what it is or does?
I have used this, it is fantastic; it will work with your old C++ code straightoff, & also accepts javadoc-style comments. Handles the worst code elegantly. Draws pretty graphs for you. Does the bits of a programmer's job that really ought to be automated.
Any concept sounds simple at first; for example, football (in England) is about "kicking a ball into a net". Similarly, putting "straight text in tags" seems straightforward at first but the complexity comes from the process required to implement a system around XML. Firstly, you need an XML parser - which is surprisingly non-trivial to write as there are many rules. Secondly, if you need to encode binary data, you have to use MIME or similar. Next, you need to write objects to receive XML data from the parser, as data cannot be read directly from the XML document itself (e.g. you have entities). XML-based programs, in my experience, tend to be unnecessarily unwieldy as XML is poor for representing data structure and does need parsing/serialisation to be used. For these reasons, a binary tag/length/data random access format will always win out eventually in terms of simplicity.
The web browser was the W3's (or, as it was, CERN's) big killer app. In the good old days they used to actually make things to prove that their standards would lead to useful technology. Do you really believe that the W3 should solely chair committee meetings and never get their hands dirty? Can good technology be designed in a vacuum? There is no seperate world of "standards bodies" here and "software houses" there - the most successful way to create a standard is to lead by example, and release a reference implementation. Presumably the W3 must have a prototype implementation somewhere; if they released it, more people might take their standards seriously. As it stands, a standard with no implementation can only be evaluated on by speculating about its theoretical merits - which is a risky strategy.
A useful framework for some types of data it may be (specifically, markup data), but I feel that XML is too often used outside the scope of its main strengths. Specifically, object serialisation, transmission and other such protocols are handled more elegantly by ASN.1, Java serialisation (which can just as easily become a standard for other languages) or just rolling your own, program semantics by LISP syntax etc.
Far too often W3 encourage the blinkered approach that XML is the only way to express things. Stuffing base64-encoded strings into markup tags to be parsed at the other end is just not convenient and I think it can be done better.
With XML, we are losing many useful syntaxes in the quest for a one-size-fits-all syntax that is actually quite bloated and hard to parse. Plus, the temptation to put everything into the same model is overwhelming. Just look at the readability of XSL - pure madness.
Many XML advocates try to kill 3 birds with one stone:
For structured data representation & code
For markup
for data storage
Personally I wish that if there had to be one standard syntax for human-readable data representation & code it was at least something sensible like LISP - at least then I can do paren-matching in my text editor. As for markup, SGML does have many advantages (the only disadvantage from XML is its alleged complexity), and as for storage, you can use actual databases to put our data in (you can argue the toss about RDBMS vs ORDBMS/XMLDBMS, though I think traditional RDBMS are fine really).
Really though I hope people will learn to use lex/Yacc and choose a syntax or structure most appropriate for their needs. I have seen many a programming team replace a syntax that works with XML syntax because it is seen to be more modern. To me this is throwing out the baby with the bathwater.
Yet another dull-as-dish recommendation from the W3C, not even a reference implementation to play with.
Ever since they have gone XML-with-everything they have produced ineffectual standards that are not followed by anybody as they are a pain in the ass to implement. It is no wonder that M$ and Sun prefer to create de facto standards instead of waiting for these guys to actually do anything. The killer app is the way to create standards and it's been a dozen years since we've seen one from the W3.
Why, given a new project, should your boss focus on language features? Much time is wasted masturbating over the technology used rather than how it is supposed to actually solve business problems. I would advise you to tell your boss where to stick his feature list, and concentrate not on language wars but how to provide the best solution in a pragmatic, cost-effective and timely manner.
Many ideas that would be seen as cutting-edge nowadays were in Lisp 40 years ago. For example, check out how Lisp can express data hierarchies and implement domain-specific languages far better than XML (e.g. look at the mess of XSL and look how DSSSL could have been).
This sort of technology was ignored back then as nobody thought they needed it, and totally forgotten about. Trust me, Lisp is more than just a historical curiosity!
Even though it would be nice if things were simple, there is no clear division between "markup" and "programming" languages. XML may be a good syntax for markup languages but is used increasingly to represent data structures. The point here is that Scheme is better at representing data structures than XML. It is also better at representing algorithms. So use XML when you really want to do markup, and Scheme when you want to do any data representation or programming.
Incidentally, XSL is based on Scheme. This is a situation where XML is being used as a meta-syntax for a programming language.
The relative novelty of XML means that people are still enthusiastic enough to really make it want to work, but there's really little advantage in using a "native" hierarchical model. I am particularly enjoying the spectacle of the XML community re-inventing the wheel with XSL/XQL/SOAP etc.
Any so-called "impedance mismatch" in RDBMs are trumped in spades by the problems of using XML/hierarchies, which not only scale badly to high volume but also lack integrity constraints and are less type-safe than databases.
Oracle have refid which I have never needed to use but understand is able to solve the remaining 1% of XMLers' problems with RDBMs.
The issue with SOAP is not one of security - what port you run on is neither here nor there - but the fact that most technologies based on XML are a load of old rubbish.
XML may be a "standard" but so are technologies such as Java serialisation and they work just fine over HTTP. This works automatically and leads to fewer programming errors due to "impedance mismatch", surely the chief source of any security holes and other bugs.
I don't buy the argument that an XML schema is any more future-proof than a Java class spec. Java handles class changes etc. quite elegantly. And I don't buy the "XML is language-independent" line either - it's just hard to read XML in any language. So you have to use that awful Xerces stuff that changes every 2 months, with little backward compatibility between versions.
Don't be fooled - there is simply nothing that uses XML that can't be done more elegantly some other way. XML is not a technology - it, along with SOAP, is a completely pointless standard.
Slashdot Mirror
Who said that the question was about setting up Java? The issue is that though the JDK is available it is incomplete and there are hence issues running Tomcat.
Read what you are flaming before you flame!
The question, though misworded, is about setting up Tomcat on FreeBSD which is nontrivial as the JDK is not 100% complete for this platform. As I understand it, many java applications need modification to get them running properly on FreeBSD, even though they may work perfectly well on Linux, Windows and Solaris.
Hopefully Sun will start to release official JDK/JREs for this platform very soon.
Because it only came out in 1995.
Also, old does not necessarily mean bad; universities still teach LISP (out in 1958) and quite rightly so.
I think raising the performance problem is splitting hairs - the fact that the syntax is the same for both remote and local calls is more handy than dangerous IMHO.
I agree though that such syntactic sugar should be taken with a pinch of salt! The overstatement of the virtues of transparency leads many developers to believe that they REQUIRE transparency in everything, leads to (for example) lots of time wasted in writing persistence layers, O/R mappings and so forth whilst waiting for JDO to be released.
Good to see that not everyone's waxing lyrical about XML, EJB and SOAP these days. I agree that it's important to keep up with old technologies as well as new - the computer industry does have a terrible habit of "forgetting" really important technologies.
I am still waiting for a Common Lisp revival - many abusers of XML/XSL will kick themselves.
It looks worth a second look, but are there any articles which explain the concept in a more clear and objective manner? I have been to the aspectj site, parc/aop and aosd sites, to no avail - the articles seem a little more intent on selling the concepts rather than explaining them.
I dunno, but my mental buzzword filter kicks in reading articles like this. Or perhaps I am getting slow in my old age...
My main worry these days with new technologies is that many organisations and developers use them for namesake rather than practicality - they create a vicious circle where the job market becomes disproportionately biased in favour of technologies that are used less often but considered to be "important". EJB & XML spring to mind here - not that they are necessarily bad technologies, just that they are often over-applied just as a point-scoring exercise. And in many companies (not mine), employees are effectively rewarded for spending their time at work reading up on new technologies so that they can b.s. about them... generally leading to a bad work ethic centred around buzzwords rather than objectivity. Not that it bothers me, they are welcome to their inefficiency!
So, any links to more informative sites would be helpful, particularly one describing how it can improve productivity, quality, decrease development costs, or indeed, if it does not and why.... so far I am curious but unimpressed!
Now it may be true that other frameworks offer these benefits, plus others - but they really ought to promote them. As I have posted many times before, I have been there, done that with many frameworks and abstraction and XML-related technologies and got p***ed off with them and gone back to old-fashioned Java/Tomcat/RDBMS - what makes this particular technology any better? Perhaps the fact that it is written by the same organisation who make Tomcat (and indeed it can run under Tomcat) is a good indicator, but they really should make more of that!
You seem to do a good job of promoting Cocoon - perhaps (seriously) you could talk to Apache & be their spokesperson.... Perhaps they could include it as a sample app with Tomcat? But by the looks of things, it is an unfinished symphony, that few people use. Unless there is a compelling reason to, I simply cannot afford to take the risk of tying myself into this. Not a denigration, but a sound business decision!
As for "reinventing the wheel", it's a bad analogy. For example, I use many already-existing libraries for performing processing such as image manipulation, connection brokering etc. but they are just that - libraries, and not entire frameworks. Buying into a framework takes more consideration than using a toolkit- it is more like being given a wheel but having to take the chassis and engine too!
I may still download and evaluate Cocoon at some stage, and time permitting, as it looks interesting at least, but I would like to see the technology, and documentation, mature a little first to address my other concerns. Cocoon may be wonderful, but at the moment it inspires little confidence - hence the understandable Fear, Uncertainty, and Doubt.
You seem to have spent the day defending your favourite technology. Which is fair enough.
However, if you read my comments before making a summary judgement about my motives, you will see that they still stand.
The original poster was asking for a comparison between Cocoon and Zope. To introduce a third option - to forget them both and try JSP/Servlets/MySQL - is hardly a cardinal sin.
It is still true that there is little evidence that Cocoon offers significant advantage over JSP/Servlets. I run my own one-man business and cannot try every technology that comes out for myself. I have to rely on factors such as existing user portfolio, feature list and advantage over what I currently do to make it worth trying to do my next site in Cocoon or whatever. To date the neither the site list nor the stated advantages are that impressive. As I have said, I separate content, logic and style just fine using JSP/Java Servlet/Database.
Perhaps XML really is wonderful, but I find the mantras of XML such as separation of content/logic, language-independence etc. often achievable with less effort elsewhere; hence such mantras ruin the credibility of XML in my view. I have worked on XML-based projects and find that very often the XML side of things was really superfluous.
You say that Cocoon can handle JSPs - can it handle servlets too? Can it offer the full functionality of, say, Tomcat? There is nothing in the Cocoon overview that says this. Perhaps, if the full Java/Servlet tools were at my disposal with Cocoon (and the overview stated this), I may consider it, but just JSP support alone is not enough for my purposes. I have much Java/Servlet code that supports my web development.
At the end of the day I am not trying to start a flame war - claiming that I am "talking out of my ass" are just plain rude - I am trying to evaluate for myself, and contribute to the debate, as to how best to create web apps. I am still the most productive web developer I know (though not necessarily the best!) and attribute this productivity to my pared-down use of Tomcat/MySQL, and specialised skill in Java/SQL. To say that I, personally, have not found a need for Cocoon is just plain true. The original poster wanted opinions - so what is wrong with giving one?
Vendors often claim that solutions are scalable as an excuse for their complexity. In reality for the amount of extra effort involved in using a given framework, plus the extra cost (for example, EJB servers cost thousands of pounds, except for JBOSS which makes fewer such claims anyway), you could hire another programmer to scale an application within the same timescale and budget.
.bombs missed out on. You look at most successful websites and find that they started out as a hack with little regard for scalability. Getting the job done in the first place is more important than predicting how the site will cope with 1000 users per minute!
In addition, the bottleneck for web applications is most often the data store - so using a faster server or a scalable database (e.g. oracle), and buying more HTTP servers, using connection pooling etc. is often solution enough without buying into a costly framework.
I think that there are many issues with scalability that are lost in the hype and not really addressed properly. For example, downward scalability is just as important: handling the simple cases with minimal hardware and development time is something that many
I don't want to rant for too long, but for my part, I have tried EJB and O/R wrappers and find them overrated and really miss the mark in many ways. If by scalability we mean "performing well under load", there is little substitute for well-written SQL and a fast DB server. Again, the "cacheing" claim of EJB etc. have yet to be substantiated.
My final two pence to anybody building a site is to design around a database schema and work "backwards" to find the appropriate supporting framework. This way, I can switch between Java, Python, Perl and whatever (even use them simultaneously) and my site data - the most important thing - will not be invalidated. On the other hand, I have found that basing the site around a particular framework is a recipe for vendor/language lock-in.
I am currently looking into a similar project myself but am considering the roll-your-own JSP/Servlet/Mysql against Zope. I have little evidence that Cocoon is a viable framework, much of the talk surrounding it seems like XML rhetoric.
At the end of the day my trade-off is one of flexibility versus ease. With Zope it is possible to hit the ground running, and it is usable to a large extent by non-programmers (in short, potentially less expensive to maintain a site). With the Java JSP/Servlets/MySQL, the sky is the limit, you have little "framework" as such to box you in, though you do have to work hard for it. Having said that, I am still going with the Java approach for the moment - a reasonable content-management site only takes around a week or two to do from the ground up, once you get the hang of it.
As for seperating content from style, I put the data in a database, use JSP templates designed by a HTML designer, and Java code. I have not really found a need for something like Cocoon at all as yet - with Java we have so many tools at our disposal to begin with.
Cheers for the advice - I have literally in the last half hour downloaded Zope for the first time ever, installed it, installed Squishdot and created a test site.
For all the talk of many other CMS I have yet to see anything as instantly usable as this. Perhaps I will reach the limit of this as I do with many other frameworks, but it's looking good so far for what I want to acheive....
Later on we would require e-commerce and so on. Any real-life developer experiences would be useful to hear of; I have had a look at a few sites that use Zope and they seem ok.
Open Source talks about freedom to use, but it also means freedom to choose. FreeDOS gives people another choice. If you don't want DOS, try something else
Does closed-source software not offer the same merits? I used DR DOS for a while too. PC-DOS also existed. Then there was GEM vs Windows, and later on we had OS/2. Let's not over-exaggerate the virtues of open-source - next we will be claiming, rightly but superflously, that it low in cholesterol!
Go and try it. Of course it cannot do your whole job for you, but a major step in understanding old code is to understand the class hierarchy. It is not a whole big app - you just run it on the code and it spits out HTML + diagrams. How can you say that it is useless if you have never used it and do not know what it is or does?
I have used this, it is fantastic; it will work with your old C++ code straightoff, & also accepts javadoc-style comments. Handles the worst code elegantly. Draws pretty graphs for you. Does the bits of a programmer's job that really ought to be automated.
Any concept sounds simple at first; for example, football (in England) is about "kicking a ball into a net". Similarly, putting "straight text in tags" seems straightforward at first but the complexity comes from the process required to implement a system around XML. Firstly, you need an XML parser - which is surprisingly non-trivial to write as there are many rules. Secondly, if you need to encode binary data, you have to use MIME or similar. Next, you need to write objects to receive XML data from the parser, as data cannot be read directly from the XML document itself (e.g. you have entities). XML-based programs, in my experience, tend to be unnecessarily unwieldy as XML is poor for representing data structure and does need parsing/serialisation to be used. For these reasons, a binary tag/length/data random access format will always win out eventually in terms of simplicity.
The web browser was the W3's (or, as it was, CERN's) big killer app. In the good old days they used to actually make things to prove that their standards would lead to useful technology. Do you really believe that the W3 should solely chair committee meetings and never get their hands dirty? Can good technology be designed in a vacuum? There is no seperate world of "standards bodies" here and "software houses" there - the most successful way to create a standard is to lead by example, and release a reference implementation. Presumably the W3 must have a prototype implementation somewhere; if they released it, more people might take their standards seriously. As it stands, a standard with no implementation can only be evaluated on by speculating about its theoretical merits - which is a risky strategy.
A useful framework for some types of data it may be (specifically, markup data), but I feel that XML is too often used outside the scope of its main strengths. Specifically, object serialisation, transmission and other such protocols are handled more elegantly by ASN.1, Java serialisation (which can just as easily become a standard for other languages) or just rolling your own, program semantics by LISP syntax etc.
Far too often W3 encourage the blinkered approach that XML is the only way to express things. Stuffing base64-encoded strings into markup tags to be parsed at the other end is just not convenient and I think it can be done better.
Many XML advocates try to kill 3 birds with one stone:
Personally I wish that if there had to be one standard syntax for human-readable data representation & code it was at least something sensible like LISP - at least then I can do paren-matching in my text editor. As for markup, SGML does have many advantages (the only disadvantage from XML is its alleged complexity), and as for storage, you can use actual databases to put our data in (you can argue the toss about RDBMS vs ORDBMS/XMLDBMS, though I think traditional RDBMS are fine really).
Really though I hope people will learn to use lex/Yacc and choose a syntax or structure most appropriate for their needs. I have seen many a programming team replace a syntax that works with XML syntax because it is seen to be more modern. To me this is throwing out the baby with the bathwater.
Yet another dull-as-dish recommendation from the W3C, not even a reference implementation to play with.
Ever since they have gone XML-with-everything they have produced ineffectual standards that are not followed by anybody as they are a pain in the ass to implement. It is no wonder that M$ and Sun prefer to create de facto standards instead of waiting for these guys to actually do anything. The killer app is the way to create standards and it's been a dozen years since we've seen one from the W3.
Why, given a new project, should your boss focus on language features? Much time is wasted masturbating over the technology used rather than how it is supposed to actually solve business problems. I would advise you to tell your boss where to stick his feature list, and concentrate not on language wars but how to provide the best solution in a pragmatic, cost-effective and timely manner.
This sort of technology was ignored back then as nobody thought they needed it, and totally forgotten about. Trust me, Lisp is more than just a historical curiosity!
Even though it would be nice if things were simple, there is no clear division between "markup" and "programming" languages. XML may be a good syntax for markup languages but is used increasingly to represent data structures. The point here is that Scheme is better at representing data structures than XML. It is also better at representing algorithms. So use XML when you really want to do markup, and Scheme when you want to do any data representation or programming.
Incidentally, XSL is based on Scheme. This is a situation where XML is being used as a meta-syntax for a programming language.
Hear Hear.
The relative novelty of XML means that people are still enthusiastic enough to really make it want to work, but there's really little advantage in using a "native" hierarchical model. I am particularly enjoying the spectacle of the XML community re-inventing the wheel with XSL/XQL/SOAP etc.
Any so-called "impedance mismatch" in RDBMs are trumped in spades by the problems of using XML/hierarchies, which not only scale badly to high volume but also lack integrity constraints and are less type-safe than databases.
Oracle have refid which I have never needed to use but understand is able to solve the remaining 1% of XMLers' problems with RDBMs.
The issue with SOAP is not one of security - what port you run on is neither here nor there - but the fact that most technologies based on XML are a load of old rubbish.
XML may be a "standard" but so are technologies such as Java serialisation and they work just fine over HTTP. This works automatically and leads to fewer programming errors due to "impedance mismatch", surely the chief source of any security holes and other bugs.
I don't buy the argument that an XML schema is any more future-proof than a Java class spec. Java handles class changes etc. quite elegantly. And I don't buy the "XML is language-independent" line either - it's just hard to read XML in any language. So you have to use that awful Xerces stuff that changes every 2 months, with little backward compatibility between versions.
Don't be fooled - there is simply nothing that uses XML that can't be done more elegantly some other way. XML is not a technology - it, along with SOAP, is a completely pointless standard.