Post #112,736
8/5/03 8:57:52 AM
|
XML Mania is driving me crazy
People are using XML for no reason except because they want to use XML. XML is a lousy protocol for passing data in most circumstances. It takes up a huge amount of space and is expensive to create and parse.
Here is a perfect example. I am evaluting connectivity from a J2EE App Server to Enterprise systems like SAP. The JCA (Java Connector Architecture) specification comes into play where you can plug in any JCA compliant resource adapter. The adapter being evaluated works as follows. The adapter provides a data mining metadata introspection tool which looks at the SAP backend and extracts metadata about a given function (what are the inputs and what are the outputs). It then generates an XML schema describing the input and describing the output.
At RUNTIME the servlet/ejb creates an XML document based on the input schema, fills in the input values received from the user, and passes the XML to the adapter. The adapter then parses the XML extracts the data and uses the SAP Java API to make the remote call. The adapter then receives the data creates an XML document based on the output schema and passes it back to the servlet/ejb. The servlet/EJB then parses the XML document and extracts the output. THIS IS INSANE!!! Why on earth would anyone want to create XML documents for no reason? Why not pass the data in a more efficient manner, after all everything is running in the app server. The JCA spec provides just such a mechanism, input and output records. In fact a competing adapter does just that. It has a similar metadata tool which instead of generating XML schemas, generates Java input and output records which match the metadata, these are then passed as regular Java objects to and from the adapter.
Of course when I mentioned this to management, the response I got was something like, Everyone knows that XML is the wave of the future, don't even bother formally raising your objections against XML, you will just look like a luddite.
The same thing is going on with Web Services. If you listen to the hype, everything will be a Web Service. If you control both sides why on earth would you want to use SOAP (XML over HTTP) when you could use a much more efficient protocol?
|
Post #112,737
8/5/03 8:59:56 AM
|
AAAAHHH!! Make it stop!
-drl
|
Post #112,738
8/5/03 9:00:04 AM
|
AAAAHHH!! Make it stop!
-drl
|
Post #112,739
8/5/03 9:01:43 AM
|
Bug!?
I didn't click twice, really I didn't. I didn't.
(hour rolled over?)
-drl
|
Post #112,882
8/6/03 3:41:07 AM
|
Uh huh.
That's like the user that said to me "the computer's not accepting my password". I said, "riiiiiiight."
He told me his password and I logged in as him.
He'd got *9* failed login attempts and he STILL insisted that the computer "wasn't accepting" his password.
Moral? Computers make mistakes, but to really fuck things up, you need a human.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Blog]
|
Post #112,742
8/5/03 9:33:30 AM
|
There are only two reasons to use XML:
1) The data needs to be human-readable.
2) You don't control both sides of the connection. Writing one-off parsers for every single proprietary messaging format is a pain.
3) You want extremely loose coupling between two systems that don't share some kind of generic communication framework (RMI, CORBA, whatever), and you can survive the performance hit.
OK, three reasons to use XML.
People who want to use XML everywhere go under my "always or never" rule.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #112,744
8/5/03 9:37:21 AM
|
Re: There are only two reasons to use XML:
I think most of the world likes 1) - it's the COBOL syndrome.
-drl
|
Post #112,746
8/5/03 9:56:46 AM
|
Does our situation fit your criteria?
We've got a bunch of c++ functions running on a variety of Windows boxes.[1] We're running our website with PHP on Linux. (Soon to be PHP on OSX.[2]) The c++ functions encapsulate a lot of the business rules, so we'd like to use them directly rather than reimplement in PHP.
What we're doing is passing an XML request from the web server to an app server that extracts the request and passes it on to the appropriate function. The results are returned in XML and extracted by the calling PHP script.
Cool thing IMO is that once we upgrade MySQL[3] we'll be able to use the same exact method. Basically we're going to encapsulate the business rules behind an XML interface so the Windows apps, webserver, DBs and whatever else we may add in the future will have a common API.
Or we may just be doing it because XML is cool, I haven't made up my mind on that yet.
[1] Yes Scott, I know.
[2] Look, I know, OK? I'm not the one making the decision.
[3] See above.
===
Implicitly condoning stupidity since 2001.
|
Post #112,758
8/5/03 10:55:14 AM
|
That's part of what Scott meant by "loose coupling".
And if he didn't, he does now. :)
I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
|
Post #112,780
8/5/03 12:54:45 PM
8/21/07 6:36:15 AM
|
Only you are using the data
You are both the producer and consumer of the data in the requests as far as I can tell - you could use whatever you want. I'd use PLists. I have code that does PLists and they are smaller and easier to parse than xml. Plus the data structure you get back is sane. Not some electric koolaid acid candy colored DOM thing.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,782
8/5/03 1:07:42 PM
|
Got a link for PLists? (google give too many to dig through)
===
Implicitly condoning stupidity since 2001.
|
Post #112,793
8/5/03 3:01:09 PM
8/21/07 6:36:27 AM
|
Explain it right here
PLists are arbitrary combinations of dictionary, list, and strings.
to encode a string - if its a token (only letters, numbers, and maybe dot) just write it. If it has any other character encode it like a C style string constant (\\n\\r\\t\\ \\"are the main escapes) and put it in double quotes.
to encode a list its ( item1, item2, item3 )
where item[123] is any plist element
to encode a dictionary its { key1 = value1; key2 = value2; }
where key[12] and value[12] is any valid plist element.
Thats it. I have a java class that does this - if you want I can sent it to you and you can port it to C++.
The interface is a stream. PList.write(aPlistObject); and object = PList.read(aStream);
Two functions. Very simple to write. Express any structure in the world. Human readable.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,797
8/5/03 3:22:38 PM
|
How about multi-dimensional arrays?
===
Implicitly condoning stupidity since 2001.
|
Post #112,800
8/5/03 3:47:06 PM
8/21/07 6:36:32 AM
|
Lists of lists
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,869
8/6/03 12:42:46 AM
|
Re: Only you are using the data
Todd: [...] I'd use PLists. [...]
Have you seen Yaml? ([link|http://www.yaml.org|http://www.yaml.org])
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #112,951
8/6/03 4:20:24 PM
8/21/07 6:39:28 AM
|
Too complicated
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,946
8/6/03 3:24:33 PM
|
Was just reminded that's not always going to be true
We anticipate exposing this interface so customers can update status on their orders, add remarks, etc directly from their own systems. Rather than have one interface for internal use and a separate one for external use, we're just going to build the one public interface and then use it internally.
===
Implicitly condoning stupidity since 2001.
|
Post #112,944
8/6/03 3:17:26 PM
|
Re: There are only two reasons to use XML:
There's one more reason to use XML: XML schemas. XML schemas are neat because you can express fairly complex datatype restrictions in it, and catch violations at parse time. This is a significant win; just like you don't have to write a lexer/parser for each app, with schemas you no longer have to write a type-checker at each input interface. Nice!
Unfortunately, I've lost count of the number of different, incompatible approaches to this idea. The last time I looked at it seriously (a couple of years ago) there were at least six different schema languages. Oops.
Also, there's a very good reason *NOT* to use XML: XSL. The transformation language is really stinkingly ugly. It's like a simple functional language from which they've removed the user's ability to write functions -- wtf? Worse, they put it in XML syntax, which makes it nearly unreadable. XSL's predecessor technology DSSSL is superior to it in basically every regard. If you have to use XSL I just feel pity.
|
Post #112,947
8/6/03 3:36:24 PM
|
Agreed.
Although I give more weight to the other decision points. Validation is a nice thing, but only if the protocol makes sense in the first place. There are plenty of easy ways to write generic validators.
Agreed on XSL/XSLT. What a heap of steaming dung.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #112,949
8/6/03 4:10:55 PM
|
An effort to make this constructive and educational
Agreed that XML is a good theory gone horribly wrong. Anyone want to share favorite (or just currently interesting) IPC/RPC mechanisms?
I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
|
Post #112,953
8/6/03 4:22:17 PM
8/21/07 6:39:38 AM
|
PLists on sockets
dead easy.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #112,787
8/5/03 2:02:13 PM
|
Luddite standing in the way of progress! :)
The hardware upgrade cycle is dependent on doing less with more. How can Intel sell you another processor, Dell sell you another machine, and Microsoft sell you another OS if you maintain your current attitude?
For that matter, how can your PHB get to manage an increasing budget?
Alex
A government which robs Peter to pay Paul can always depend on the support of Paul. -- George Bernard Shaw
|
Post #112,817
8/5/03 6:54:02 PM
|
XML - Some Thoughts
1. XML is less efficient as an EDI tool than most of the prior protocols (X.12, EDIFACT, etc.) We wrote a very efficient EDI protocol of our own at SABRE, which was a minimalist version of EDIFACT. No argument here. If you're paying for data by the byte (or megabyte) and you're doing a lot of EDI, then XML is not for you.
2. XML is human readable. Well, only if it doesn't get terribly complicated. If it gets complicated, then you can throw it into an XML-enabled browser or some other display tool and look at it. Even then, if you're looking a something as complex as a home loan application, it is going to take some time to go through all the data (especially if they embed your last 2 year's tax returns :-) ).
3. XML is standard. We'll we're trying. Only Microsoft wants a proprietary version for Commerce Edition, IBM wants their flavor. Then trade groups want to define "standard" transactions for their industry. Sadly, I just finished a job at a pharmacy benefits company, where the industry is moving to another version of their own proprietary EDI protocol. They completely missed the boat with respect to XML, and it will be 5-10 more years (long after XML has faded as a fad) before they even think about it.
4. XML is easy to use. Well, at least there's a standard parser, or two, or three. But don't get me off into the meta data definition piece of it. DTD's are ugly. XMLSchema is worse. Then there's the worst part XSLT style sheets. Very complicated. Maybe in a few more years, there will be better tools.
5. Securing XML. Since it is plain text, it has to be encrypted to be sent/received securely. But with what protocol? SSL? Secure FTP? (which flavor?) How about AS2 (that's what my company sells). Without security, how can you be sure the XML message really came from the person/place that it appears to have come from? How do you feel about it when SOAP messages actually publishing services comes around? How do you know that you're really even sending your precious personal data to the right service and not some "spoofed up" fake?
That list should make you want to run from the room screaming... Like DeSitter did already.
:-)
But, at least change is providing stable employment for me. If things stay the same, then most of us on this forum would probably be out of work.
Glen Austin
|
Post #113,219
8/8/03 3:49:01 PM
|
Winnah! of the Lucid Post of the Month award!
People are using XML for no reason except because they want to use XML. Would be funny...if it weren't so true (and sad). jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #113,309
8/9/03 1:48:22 PM
|
Let's promote a relational alternative
I have been kicking around a "cleaned up" version of comma-delimited formats that have schema definitions. It is roughly 1/3 the size of equiv XML data because it does not repeat the column names for every record and no closing tags that dupiclate the opening tags. XML data is for people who spit on relational theory.
________________
oop.ismad.com
|
Post #113,365
8/9/03 10:53:56 PM
|
But...
Fundamentally, Relational is rows and columns. If you're problem isn't rows and columns, then relational doesn't work.
I realize that you can throw a bunch of tuple stuff at me, but at the bottom, that's what a pure relational DB is.
I've looked at some of the Object Relational extensions to DB2 and Oracle, but it's just not taking off. A few places are using it, but there's no "ah ha" to it.
I've also seen 3-4 examples of XML being stored in database, both as a whole document and with "shredding" technology.
What I'd like to see, is someone who fundamentally has an object database, but then allows you to relationally "index" pieces of the object, like a relational database.
The problem there is, that with object technology, you have to deal with context information, that you don't have to worry with in Relational. It's all tuples, global scope, with GRANT rules deciding whether you can see it or not.
|
Post #113,415
8/10/03 9:12:24 PM
8/21/07 12:45:02 PM
|
Spitting
XML data is for people who spit on relational theory. Actually they spit on all theory. Rebels without a clue. They don't like objects either. They like streams. And links. And documents. And transformations written in heiroglyphics. The think they like schemas - but everytime they try to say how to define one they screw it up and throw it out.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #113,423
8/10/03 11:59:15 PM
8/11/03 12:08:18 AM
|
But you see, Todd?
That's what all PHB's want.
Programming that is simple enough they can understand and staff for. Programming that is simple enough that they can hire anyone/anywhere to do it.
Simple enough that they can train their their mistress in a few months to do it, or at least pretend to do it (yes, this happened to me at a prior job).
PHB's want programming that solves complicated problems with a very simple solution. That makes them look good, get promoted, make their quota, and get their bonuses.
That's why they engage lots of salespeople. These people are supposed to make up for their lack of management/development skills by finding some vendor to provide them (and the company) with a miracle technology to solve all their problems. And, the salespeople usually buy them lunch (and a whole lot more).
They want silver bullets. Right now, XML is a silver bullet.
I guess that's my problem. I hate PHB's enough to not want to become one. Yet, as I get older, I realize that I no longer have the stamina to work all night, or for 72 hours straight to solve problems. I'm getting tired of everyone's emergency costing me a weekend (or vacation) with my family.
I still code/solve them faster than most young-en's I know, with much better quality and tighter design.
But I'm getting tired of silver bullets. And the sad thing about most silver bullets is that once you build something relatively complicated with it, the problem set is usually as/more difficult than doing it in the last silver bullet technology.
But I continue to learn the silver bullet languages, simply because I want to keep working.
I coded and tested 4 C++ classes on Friday (2 were linked lists) in about 4 hours. I did a little more testing tonight, but basically, what I had worked. I did XP and wrote a test program to build the lists inside the lists to make sure it worked.
I'm tired of the PHB's running things. I want smart people to run things.
Edited by gdaustin
Aug. 11, 2003, 12:08:18 AM EDT
|
Post #113,434
8/11/03 4:29:07 AM
8/21/07 12:45:28 PM
|
I don't think its the PHBs
There are a lot of otherwise smart people running down this blind alley. Go join the XMLDev list and watch it for awhile. I've done my time there.
[link|http://lists.xml.org/archives/xml-dev/200210/msg01514.html|http://lists.xml.org...210/msg01514.html]
Personally, I think they're nuts.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #113,468
8/11/03 11:51:09 AM
|
Another possibility...
Some of them are what I call "sold out".
What I mean by that is that they are chasing that the money-holders want simply because they need a check. It happens frequently in tough times.
Tough times are a refining fire that test what you really believe. Watch people during these times, because you find out what they're really made of. People who don't believe in a particular language strongly will "sell out" to the new thing, even if it violates their prior strongly held beliefs.
Now, I'll admit that I switch languages, because I don't worship a particular language. But, I'm not claiming to be an expert in C++ or Java, either (like Bruce Eckel). I use them as tools to do work. I bitch about what doesn't work in them, and try to propose better alternatives, when given the chance.
I'll probably take a look at Squeak, when I have time. Because, from an OO perspective, I think SmallTalk makes sense, especially now that interpreted environments are taking over from "compiled" executables.
I think Java was the key language to make it over the hump, from compiled to interpreted. Our "new technology" group looked at Smalltalk in the early 1990's and machines were simply not powerful enough, then, to use an interpreted language. That, and many of the powerful algorithms were probably not built into the language at the time.
I'll be honest, I think that Oracle and IBM give Java a bad name, still, because of the bloated products they have put out using Java. But, I think it's more because of programming by committee, than because Java is a bad language. I'll admit I haven't gone very deep into Java Swing classes, and from what I have done, they seem difficult and clunky to me. For GUI programming, there probably is a better way.
However, I worked on Java multi-threaded server application for a pharmacy claims company. The tools for writing good threaded/sockets code which parsed messages were definitely there. And I think with the addition of Jython and the use of the SAX/DOM, and some of the parsing infrastructure that is there, Java could become the lingua franca of the transaction processing industry.
|
