XML in .net SUCKS!
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
XML Serialization ;P xacc-ide 0.0.15 now with C#, MSIL, C, XML, ASP.NET, Nemerle, MyXaml and HLSL coloring - Screenshots
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
I've written one about XML in .NET[^]. In Czech languge, covers "only basics". If I'll have time I'll revise/update/tranlate it then. Why you didn't ask in XML forum if you had/have any problem, btw? Christian and I reside there, I am sure we can handle few rants :-D David
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
Well, not that you wanted a response to your rant (nice rant, BTW), but I personally find .NET's support for XML incredibly easy to use. If you want something easier, try this[^] out. The only time I gnashed my teeth with the DOM was when I was writing an XSD editor for a client. A full blown, everything under the sun, editor. Lots of fun. But for simple stuff, the XmlDocument class is really easy to use. Marc My website
Latest Articles: Undo/Redo Buffer Memento Design Pattern -
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
I'm still unclear on exactly what you're having problems with, but I've written tons on the .NET XML classes (both in books and articles) and find them to be extremely easy to use (both the sequential and the DOM stuff).
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
use xpath "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
John Cardinal wrote: If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). doc.SelectSingleNode("/doc/record").Value Where doc is a variable of type XmlDocument, and "/doc/record" is the XPath of your record. If you assign to it, you can write. If you use on any other expression, you can read. It's not that hard. If you don't know enough about some tool, it's not wise to judge its value. I see dead pixels Yes, even I am blogging now!
-
[RANT] This is not a programming question, it's a rant, move along, nothing to see here, I just got tired of ranting to my co-workers who don't need to deal with this stuff and understanding nods aren't enough. It's becoming clear that Microsoft thinks the best way to support XML in .net is to code it so close to the DOM that it's all but unusable. Twice now in two major projects I've attempted to use it. Both times I've found it relatively easy to write XML and now after both times spending hours trying to read XML back that I wrote, simple flat XML with one record only and several fields, I've given up and gone back to reading in the XML to a dataset as it's the only way that works. It's obvious from the sheer quantity of XML related objects that there is something very wrong with that whole area of .net. There are dozens of ways of reading and writing XML, none of them separate you from the underlying standard in the way that most modern .net objects do. .net makes nearly anything easier to do but XML. Why write a bunch of objects that force you to do what is essentially very little removed from writing your own parser. In their objects you still are forced to manually move from node to node, element by element, it's ridiculous! XML is a good theory and looks so simple and easy to use when you look at the data itself, but the very moment that you go to implement it you get stuck in a quagmire, a mess of code that is very close to the "dark ages" of computing and software development. No wonder people make their living with this stuff, it's so arcane it's almost unusable. It reminds me of the old days when you needed to beg an all knowing, condescending, system admin to do just about anything on a network and those bastards all must have been hired to write the XML code in .net. If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). [/RANT]
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
Stuff that sucks: Installshield. At least the Profesisonal Standard Version. And the one I tested. Doc-to-Help, for a broken concept, and trying to fix that broken concept with an extra layer of metacomplexity. Gigasoft ProEssentials for having a damn ugly API*) but the fastest and most scientific chart at the market, then spending years to add shiny colorful backgrounds instead of fixing bugs, then spending years to add shiny colorful .NET backgrounds instead of fixing bugs, then climaxing the price for their single most target market: people who want to display gadzillions of points many points as fast as possible. guess which things I worked with today. *) To give credit where credit is due: After Installshield and Doc-to-Help, the PE API i actually quite decent.
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen -
use xpath "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
-
John Cardinal wrote: If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). doc.SelectSingleNode("/doc/record").Value Where doc is a variable of type XmlDocument, and "/doc/record" is the XPath of your record. If you assign to it, you can write. If you use on any other expression, you can read. It's not that hard. If you don't know enough about some tool, it's not wise to judge its value. I see dead pixels Yes, even I am blogging now!
-
John Cardinal wrote: If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). doc.SelectSingleNode("/doc/record").Value Where doc is a variable of type XmlDocument, and "/doc/record" is the XPath of your record. If you assign to it, you can write. If you use on any other expression, you can read. It's not that hard. If you don't know enough about some tool, it's not wise to judge its value. I see dead pixels Yes, even I am blogging now!
Right, ok, you're willing to stand up and proclaim that Microsoft couldn't have done it any better or made it any easier than it is now? That there is no possibility to abstract it to a higher level at all?
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
-
Right, ok, you're willing to stand up and proclaim that Microsoft couldn't have done it any better or made it any easier than it is now? That there is no possibility to abstract it to a higher level at all?
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
John Cardinal wrote: Right, ok, you're willing to stand up and proclaim that Microsoft couldn't have done it any better or made it any easier than it is now? There's always an easier way. But, the DOM and the SAX parsers, the XmlSerializer and the DataSet support makes it extremely easy to use. I don't know what you're coding, but if you're having trouble using the XML APIs, you'll have a hard time doing anything in the .NET world, as it is one of the easiest APIs provided. I see dead pixels Yes, even I am blogging now!
-
John Cardinal wrote: Right, ok, you're willing to stand up and proclaim that Microsoft couldn't have done it any better or made it any easier than it is now? There's always an easier way. But, the DOM and the SAX parsers, the XmlSerializer and the DataSet support makes it extremely easy to use. I don't know what you're coding, but if you're having trouble using the XML APIs, you'll have a hard time doing anything in the .NET world, as it is one of the easiest APIs provided. I see dead pixels Yes, even I am blogging now!
Daniel Turini wrote: I don't know what you're coding, but if you're having trouble using the XML APIs, you'll have a hard time doing anything in the .NET world, as it is one of the easiest APIs provided. that's just plain wrong. We've been working with .net for over 2 years now and are nearing completion on a substantial n-tier business application and have not come across anything nearly as arcane or difficult to use. I agree the DataSet support is dead easy, but that's the only thing so far that I've come across that is. The problem is that the API appears to follow exactly the underlying DOM without any consideration of abstracting it to a higher level which is where we come in. I've been working with ADO and earlier technology since it's inception and XML on the surface looks pretty simple but most of the API's related to XML are doing anything that I would expect them to do. I suspect it's a fundamental misunderstanding of XML itself, but to call it one of the easiest API's out of all of .net is pretty off the wall. Easy perhaps if you have a very good to expert knowledge of the W3C specs, but I thought the whole point of a framework was to abstract that stuff. I could write a text file parser that uses regular expressions to parse out the data I want in about half an hour, so far I've spent hours trying to read in and extract globalized data fields from a simple flat (one record) XML document in memory. That just doesn't seem easy to me.
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
-
John Cardinal wrote: Right, ok, you're willing to stand up and proclaim that Microsoft couldn't have done it any better or made it any easier than it is now? There's always an easier way. But, the DOM and the SAX parsers, the XmlSerializer and the DataSet support makes it extremely easy to use. I don't know what you're coding, but if you're having trouble using the XML APIs, you'll have a hard time doing anything in the .NET world, as it is one of the easiest APIs provided. I see dead pixels Yes, even I am blogging now!
Daniel Turini wrote: I don't know what you're coding, but if you're having trouble using the XML APIs, you'll have a hard time doing anything in the .NET world, as it is one of the easiest APIs provided. that's just plain wrong. We've been working with .net for over 2 years now and are nearing completion on a substantial n-tier business application and have not come across anything nearly as arcane or difficult to use. I agree the DataSet support is dead easy, but that's the only thing so far that I've come across that is. The problem is that the API appears to follow exactly the underlying DOM without any consideration of abstracting it to a higher level which is where we come in. I've been working with ADO and earlier technology since it's inception and XML on the surface looks pretty simple but most of the API's related to XML are doing anything that I would expect them to do. I suspect it's a fundamental misunderstanding of XML itself, but to call it one of the easiest API's out of all of .net is pretty off the wall. Easy perhaps if you have a very good to expert knowledge of the W3C specs, but I thought the whole point of a framework was to abstract that stuff. I could write a text file parser that uses regular expressions to parse out the data I want in about half an hour, so far I've spent hours trying to read in a simple flat (one record) XML document in memory. That just doesn't seem easy to me.
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
-
John Cardinal wrote: If anyone want's to write an article showing a simple method of writing a single record of data then reading back that data using Microsoft's own objects I will call that person a hero (if in fact it's even possible). doc.SelectSingleNode("/doc/record").Value Where doc is a variable of type XmlDocument, and "/doc/record" is the XPath of your record. If you assign to it, you can write. If you use on any other expression, you can read. It's not that hard. If you don't know enough about some tool, it's not wise to judge its value. I see dead pixels Yes, even I am blogging now!
Daniel Turini wrote: doc.SelectSingleNode("/doc/record").Value now that is a useful piece of information on XML! :D after considerable fiddling around i wrote the code to read in my recursive XML document using XmlTextReader, and working through the tree one node at a time. it seemed the best solution for what i was trying to do. but now all i want is a simple way of reading specific bits of data out of a simple XML document. i was getting fed up bouncing around inside the XML documentation *sigh* thank you for making my life so much easier :D zen is the art of being at one with the two'ness