[tarballed]

hello everyone.

Things have taken a taken a very interesting turn for me in the last 4 weeks. The short story is that my Manager was fired and I am working to replace him, which is what I want.

What does this have to do with XML? Nothing really. However, he is a low-down of what I am doing.

First, I am un-FUBAR'ing everything my former Manager did. When I say FUBAR, I really mean FUBAR'D. I could write a full thread on it.

With that out of the way, I am trying to make things a lot better for our company; making things more efficient, easier to use, access to data we need today, not in 3 weeks. As I pour over our requirements and needs, I am realizing that XML can help me do quite a few things with data that can be very beneficial to our company. I figured, mine as well get started.

With that, was curious if anyone had recommended books, websites, online learning centers that could be beneficial. This would not only be for me, but for another person in our company as well (She is not terribly tech savy, but she is very smart.)

Here are a few books I quickly found on Amazon. Anyone used them before?

XML O'Reilly (www.amazon.com/exec/obidos/ASIN/0596004206/qid=1115915226/sr=2-1/ref=pd_bbs_b_2_1/102-8186252-9968114)

XML For Dummies (www.amazon.com/exec/obidos/tg/detail/-/0764516574/qid=1115915226/sr=1-10/ref=sr_1_10/102-8186252-9968114?v=glance&s=books)

Amazon List (www.amazon.com/exec/obidos/search-handle-url/ref=dp_searchBox_1/102-8186252-9968114?url=index%3Dstripbooks%3Arelevance-above%26dispatch%3Dsearch%26results-process%3Dbin&field-keywords=xml&x=0&y=0)

I appreciate it.

[frisco]

I don't have any suggestions for you, but am curious as to why you believe XML will help. Not that i don't think it can, i'm just curious where it can be used appropriately in a particular company.

I see the usefulness of XML in some config files, but sometimes it's more the Rube Goldberg solution to problems. For company-wide data it seems generally the better option is to throw it in a central db somewhere.

So, if you have the time, i'd like to know the reasons you have.

[bmk1st]

Maybe this will help? http://www.w3schools.com/xml/default.asp

[tarballed]

I don't have any suggestions for you, but am curious as to why you believe XML will help. Not that i don't think it can, i'm just curious where it can be used appropriately in a particular company.

I see the usefulness of XML in some config files, but sometimes it's more the Rube Goldberg solution to problems. For company-wide data it seems generally the better option is to throw it in a central db somewhere.

So, if you have the time, i'd like to know the reasons you have.

No worries.
Sort of a long story, but i'll do my best to keep it short.

Recently, my direct manager was fired. That's a whole story in itself. But basically, he was so stubborn and arrogant that he made things 100 times more difficult to do things than they really needed to do. Because of that, my company is suffering the repercusions which I am frantically trying to fix (so far, i've had very good success in doing so).

Anyway, I am going to be working with A LOT (stressing that) of data here. Data for our customers (We are a mortgage company, so you can imagine all the data.) We are bringing on board a CRM (Siebel) that is rather large and complex. We also run a rather large system here that does our processing.

The point is that I really wanted to find out if XML is going to allow us to retrieve data from different data sources and allow us to exchange it/import into another data source. Maybe even the possibility of pulling data out of the database (Oracle) and displaying it as needed.

I'm not real familiar with XML or is limitations, but I've been reading docs on a few of these products and they make reference to XML quite a bit. Thought i'd check into it and see if it is something I can use to help out.

In the end, what im really trying to do is make things easier and more efficient for my users. Since we are a Mortgage company, our Loan Officers are the blood of the company. IF they do loans, we are profitable. If they don't, we are in not so good shape. Know what i mean? Right now, I am trying to un-FUBAR what my previous Manager did and believe me, its a freaking nightmare.

Ok, hope that helps.

[Kernel_Killer]

Why not PHP? A web interface can always make it easier on your clients, and you then have an easy integration with a MySQL/PostGRESQL/SQL for all your database data.

[tarballed]

Why not PHP? A web interface can always make it easier on your clients, and you then have an easy integration with a MySQL/PostGRESQL/SQL for all your database data.

Thought about it. BUT, the Application server we are going to be using, they do not recommend nor support PHP...Their recommendation was XML.

[bumbler]

Caveat: It's possible I didn't understand anything I've read on this, but I've read a lot.

In the broadest term, I believe the consensus is XML is versatile as can be. It appears database apps can be taught to read it well enough. The problem is processing can be slow because XML can be really verbose in file format. As I understand it, the old relational databases are lists within a heading. Everything within the list-as-object is known to have the characteristics of the list. Parsing is pretty simple if the application can identify the nature of the list, because the items are simply tagged with an identity to which record they belong.

To do that with XML, there is no list-as-object. Each file contains the list buried in a fat wad of code. Each item on the list is identified with several tags, and when the information there is rather simple, that's a lot of code to parse just to extract a single bit of info. The info makes up something like 25% of what's there, and often less.

Even if you organize the database so that each record is a complete file, and the items within the file are cross-referenced by the tags, you still have a fat structure to parse to find the data. You get a durable format (XML is just text) but slow processing. If your hardware is up to it, that may not make a major difference. The other problem is that tags for XML databases are without a standard. One may be emerging even now, but I've not seen it. It seems most places where it's implemented is unique and internally guided.

Is that too obvious?

[tarballed]

Caveat: It's possible I didn't understand anything I've read on this, but I've read a lot.

In the broadest term, I believe the consensus is XML is versatile as can be. It appears database apps can be taught to read it well enough. The problem is processing can be slow because XML can be really verbose in file format. As I understand it, the old relational databases are lists within a heading. Everything within the list-as-object is known to have the characteristics of the list. Parsing is pretty simple if the application can identify the nature of the list, because the items are simply tagged with an identity to which record they belong.

To do that with XML, there is no list-as-object. Each file contains the list buried in a fat wad of code. Each item on the list is identified with several tags, and when the information there is rather simple, that's a lot of code to parse just to extract a single bit of info. The info makes up something like 25% of what's there, and often less.

Even if you organize the database so that each record is a complete file, and the items within the file are cross-referenced by the tags, you still have a fat structure to parse to find the data. You get a durable format (XML is just text) but slow processing. If your hardware is up to it, that may not make a major difference. The other problem is that tags for XML databases are without a standard. One may be emerging even now, but I've not seen it. It seems most places where it's implemented is unique and internally guided.

Is that too obvious?


Nope. i follow. I think one of the big things why XML keeps popping up is that we can exchange data between our vendors/contacts, no matter what we use, as long as we use XML. Allows the data to be viewed/access on different applications if you will.

[frisco]

If your data sources and targets can already export/import to XML but lack any other standard interface, then XML is the way to go.

If they don't already export/import XML, then you'll be writing an interface to them to import/export xml. If you're already writing the interface, it seems simpler to just interface them both directly.

For example, let's say you have a mysql database and an oracle database. You could export the mysql data into xml format then import the xml into oracle. Or you could write a script to do DB selects from mysql and inserts into oracle (and create tables, etc). In this case, XML may be a longer, more inefficient path to take. If you're also throwing other sources into the mix, and there is no other standard interface across them all, then perhaps adding a util to XML import/export for each source/target is worth the time.

As an aside, XML and php are in different problem spaces. XML is a markup language, php is a programming language; XML represents data, php acts on data. In other words, your XML import/export utility could be written in php (though i might recommend something else, depending on where this is going).

Finally, it sounds like a lot of your data is strewn across various places, in various formats. Unless that's absolutely necessary, it may be better to consolidate all that into one location, like a database, and provide easy access to that, like through web interface. Will help with availability and backup and management.

And if i don't make sense, or missed something, well i haven't slept yet - went to the 12:10am RotS show and just came into work after that.

[frisco]

Nope. i follow. I think one of the big things why XML keeps popping up is that we can exchange data between our vendors/contacts, no matter what we use, as long as we use XML. Allows the data to be viewed/access on different applications if you will.

Ah ok, if you can only get/send the data from the vendors in XML then that's a way to go. I was under the impression you were accessing various resources of your own.

Are you then needing to implement your own import/export of your XML data? If so, it might be easiest to look at the XML libraries provided by your favourite language and try it out. Pressumably the XML format has already been decided by the vendor or application?

[tarballed]

Ah ok, if you can only get/send the data from the vendors in XML then that's a way to go. I was under the impression you were accessing various resources of your own.

Are you then needing to implement your own import/export of your XML data? If so, it might be easiest to look at the XML libraries provided by your favourite language and try it out. Pressumably the XML format has already been decided by the vendor or application?

I believe so. That is still in discussion, but im assuming it has.
The main thing this will be used for is the exchange of information between different systems running two completely different setups; For instance, one is a Linux server running IBM Universe DB. The other is a Windows server running a Oracle DB. Both have specific purposes, but we need the data to be transfered between each other as needed.

Eventually, the IBM Universe DB system will be retired and we will use the Oracle DB server exclusively. In the mean time, just need to get the data in and out as needed.