Hi, I just wanted to make a few minor points on this thread. I personally like XML, but given how oversold most technical approaches are, it is important to look at any drawbacks and characterize them (so I am glad Rich brought up the issue).
For transfering data between systems, XML does provide a uniform way to do it. Comma separated file type approaches also will give a certain degree of uniformity, but less than XML because of validation through dtds/xml schema. The drawback of XML would probably be the file size. For simple columns of numbers you could have overheads associated with tags that increase file size by a factor of 2-5. This would also slow the parsing of the file by roughly the same factor. For small files that may not be a problem. But if the file size gets large, it could be. Also if the file size gets large you will have to use SAX (sequential access) instead of DOM (random access, file is read into memory). SAX will be a little harder to implement than DOM for the same system. Comma separated files would not have this kind of problem, since each line is read and entered into the system receiving the data. Ultimately if you are willing to pay the overhead you can use XML. It might be nice if XML had a structure to reduce the number of tags it requires. This could solve the file size expansion that arises from the tag names. Let's say you had a system that does records the temperature as a function of time. So you have times and temperatures in the comma separated file. The XML file would look like: <tempdatapoint> <time> 12 </time> <temperature> 45 </temperature> </tempdatapoint> ... even more <tempdatapoint> elements ... A single file would have many <tempdatapoint> elements. You might want to use attributes for this data, but you would still have a bunch of extra tags. If there was a structure in XML that allowed this information to be more compact it could solve the problem. Something like: <flatelementset rowname="tempdatapoint" delimeter="," linedelimeter="\n"> <element number="1" name="time"> <element number="2" name="temperature"> 10,45 11,46 12,52 ... </flatelementset> The XML parsers like SAX and DOM would then have to be smart enough to expand the second compact notation into the first notation when it is read by a program. If anyone know whether this exists, please respond. BTW, I mean in general not as a proprietary extension. But it would be nice to know even if it was just a proprietary extension. Much more thought would have to be given to this kind of an extension. At the same time, XML does have some advantages over comma separated file type approaches. Let's say that the schema of the data you are recieving does not match well to the system you are entering it into. Maybe the comma separated file data is not normalized where the database is. If you are using XML, it is nice to use XSLT to transform the data into a schema that is more similar to the database before it is entered. I think this would be much easier than writing a parser to do the same thing. Also sometimes you may be recieving more data than you really need to enter in your database. XSLT could also be used to filter the data before it is read by your parsing program. XML might also be better if you had a richer data structure (more like trees than rows in a database). I know that trees can be emulated using rows, but it might be a little harder. I took the case I did simply because it represented the strongest objection to using XML approaches. For web applications and for any other applications, there are always many ways to achieve the same effect. And it is can be very application dependent which technology you want to use. I'll just say that I like having the option of using SOAP/cocoon approaches available. Bill Gooding --- "Richard O. Hammer" <[EMAIL PROTECTED]> wrote: > Dave Reid wrote: > > The major point is ease of interchange between > systems. I'm working on a megaproject with 25 > interfaces all to different types of systems. > Without XML as the consistent underlying standard > for all transaction interchange our work would have > been much harder, and more costly. > > Dave, > > I wonder if the advantage you mention here has to do > with the fact > that XML is text. Could you interchange data > between 25 interfaces if > the specification required ASCII or ISO-8859-1, with > the same ease > that you achieve with XML? If so, then I still do > not see the > advantage of XML. > > Rich > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
