Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
What's XML good for? 1
- Thread starter SCelia
- Start date
-
1
- #2
I asked that question about a year ago. I still can't answer it comprehensively!
I have found numerous uses. The most use I get is when I am building applications. If data is naturatly hierachical then its perfect for XML. I have been looping through recordsets with redundant data for years. When the data is in XML there is no redundant data and if I open the document up in a DOM then I can get instant access to any point in the document (and therefore specific data) using XPath. I recently had to do some complex summing based on certain values. Using looping through a recordset would have been laborious. Using XPath and XSL I did it in one simple line of code and it rusn like a rocket.
I never use recordsets to retrieve data from SQL Server anymore. I use SELECT FOR XML to get all my data natively in XML.
This allows me to manipulate and access the data in a DOM. It also allows me to use XSL to transform the data, so I can keep my presentation neatly seperate from teh data, and I use ASP to do the transformation.
On the last three projects I have done, using XML, the DOM, XPath, and XSL I have saved 25% - 30% of the development time had I done it differently.
If you get data thats hierarchical and you would normally store it in a complex object hierarchy that you build yourself, you now get it free in the form of the DOM.
If you are a developer then look at the DOM, XPath, and XSL and you will form your own ideas of what it can do for you based on what type of projects and data you work with.
James
James Culshaw
jculshaw@active-data-solutions.co.uk
I have found numerous uses. The most use I get is when I am building applications. If data is naturatly hierachical then its perfect for XML. I have been looping through recordsets with redundant data for years. When the data is in XML there is no redundant data and if I open the document up in a DOM then I can get instant access to any point in the document (and therefore specific data) using XPath. I recently had to do some complex summing based on certain values. Using looping through a recordset would have been laborious. Using XPath and XSL I did it in one simple line of code and it rusn like a rocket.
I never use recordsets to retrieve data from SQL Server anymore. I use SELECT FOR XML to get all my data natively in XML.
This allows me to manipulate and access the data in a DOM. It also allows me to use XSL to transform the data, so I can keep my presentation neatly seperate from teh data, and I use ASP to do the transformation.
On the last three projects I have done, using XML, the DOM, XPath, and XSL I have saved 25% - 30% of the development time had I done it differently.
If you get data thats hierarchical and you would normally store it in a complex object hierarchy that you build yourself, you now get it free in the form of the DOM.
If you are a developer then look at the DOM, XPath, and XSL and you will form your own ideas of what it can do for you based on what type of projects and data you work with.
James
James Culshawjculshaw@active-data-solutions.co.uk
- Thread starter
- #3
I've used XML to transfer data between clients. This is the "simple" application for XML, but it makes things much easier, especially if you define an XSD ahead of time (defines how the XML file should look - field widths, data types, etc).
You can also use XML and XSLT to render HTML files. This allows you to define web screens on a per-client basis (slow, but nice).
Chip H.
You can also use XML and XSLT to render HTML files. This allows you to define web screens on a per-client basis (slow, but nice).
Chip H.
XML is a way of formalising data for either storage or transfer between many separate systems. It allows data to be stored in a human readable format, therefore clarifying for users as well as programs what the data is there for.
XML allows many disparate groups to define their own data formats easily - hence the eXtensible part. They can also (as mentioned above) define HOW that data is to be interpretted (meta-data).
XML also helps immensely in large organisations/global (internet) systems when there are many different systems communicating with each other. As long as a XML enabled utility specifies that the data in XML belongs to them in some way, the systems can read the data that belongs to them and only them if they wish. For example, if you had an accounts package that needed to produce a report on accounts, you could identify all your xml tags with an accounts prefix, or namespace as it is known eg. <myaccounts:balance> would identify "balance" globally within the namespace "myaccounts" (with a bit more work than that, but not much).
With XML therefore, I can generate a page of XML from one system (say the accounts package again) which contains accounts information. I can then pass it on to another system, say a management package which analyses the data and appends another set of elements to the document. I now have accounts AND management data within my document, but any system (or indeed person) that wants to read it can easily identify which data is which; immensely useful, and not something that could easily be done with any other data format such as binary.
As long as the system has a parser, it can read any XML document - as long as it is accessable of course.
XML's sibling utilities (XSLT, XPATH, FOP etc) provide an exceedingly powerful way of reading, interpretting, searching and transforming data from one form into another. For example, using XSLT, I can specify templates to transform vast XML documents of information to other document types (XML, text, HTML etc) specific to my operations. With XPATH I am provided with a large number of tools to search and manipulate elements in the XML archive. And with FOP, I can transform my data into Acrobat reader format. Fantastic
I do not have any doubt about culshaja's development time being reduced by that amount. XML is not an answer to all problems with b2b (business to business) communications, but it does simplify the problem immensely.
Hope that helps,
Matt
XML allows many disparate groups to define their own data formats easily - hence the eXtensible part. They can also (as mentioned above) define HOW that data is to be interpretted (meta-data).
XML also helps immensely in large organisations/global (internet) systems when there are many different systems communicating with each other. As long as a XML enabled utility specifies that the data in XML belongs to them in some way, the systems can read the data that belongs to them and only them if they wish. For example, if you had an accounts package that needed to produce a report on accounts, you could identify all your xml tags with an accounts prefix, or namespace as it is known eg. <myaccounts:balance> would identify "balance" globally within the namespace "myaccounts" (with a bit more work than that, but not much).
With XML therefore, I can generate a page of XML from one system (say the accounts package again) which contains accounts information. I can then pass it on to another system, say a management package which analyses the data and appends another set of elements to the document. I now have accounts AND management data within my document, but any system (or indeed person) that wants to read it can easily identify which data is which; immensely useful, and not something that could easily be done with any other data format such as binary.
As long as the system has a parser, it can read any XML document - as long as it is accessable of course.
XML's sibling utilities (XSLT, XPATH, FOP etc) provide an exceedingly powerful way of reading, interpretting, searching and transforming data from one form into another. For example, using XSLT, I can specify templates to transform vast XML documents of information to other document types (XML, text, HTML etc) specific to my operations. With XPATH I am provided with a large number of tools to search and manipulate elements in the XML archive. And with FOP, I can transform my data into Acrobat reader format. Fantastic
I do not have any doubt about culshaja's development time being reduced by that amount. XML is not an answer to all problems with b2b (business to business) communications, but it does simplify the problem immensely.
Hope that helps,
Matt
- Status