XML Disadvantages
The extensive markup language is the way to go for developing future web applications, and it almost defines the future of web development. There are no doubts about its performance in this arena. However, XML also has some draw backs which need to be looked at and improved upon. The reason it faces some resistance from users is a result of these drawbacks. One of the biggest drawbacks of XML is that it is lacking in the area of adequate applications for processing.
Lack of Applications Processing
XML needs an application processing system . There are no browsers yet which can read XML. In the case of HTML, anyone can write up a program and that can be read using any browser anywhere in the world. To be able to be read in a browser, XML still depends on HTML, and is not independent of it. The XML documents have to be converted to HTML before they are deployed. The most common method is to write the parsing routes in either DHTML or Java applications and parse through the XML document. The formatting rules can be applied by the style sheet to convert the entire document into HTML.
Other disadvantages of XML include the fact that it is more difficult, more demanding and more precise when compared to the HTML. XML does not have any browser support and does not have anything to support the end user applications. It is still in the early experimental stage and hasn’t proved its mettle yet.
XML as a language is very flexible, but its flexibility can potentially become one of its disadvantages, since there may be disagreement in its tags. If an XML object has too many constraints, it might get very difficult to construct the file. It is too verbal and sometimes this may be a problem for other applications. While just describing tags and building a system sounds very easy, it may not be that easy in reality. For example, a business or professional organization may have hundreds of functions related with one set of documents. XML does not have the capability to synthesize all the information related to the document.
General Weaknesses of XML
Since XML is a verbose language, it is totally dependant on who is writing it. A verbose language may pose problems for other users. XML is not specific to any platform, and has a neutral platform requirement which may be a disadvantage in a few circumstances. All the standards of XML are not yet fully compliant. They are not fully recognized to be used yet. Users have reported problems with the parser and there are problems with XML and HTTP which are still being resolved.
Disadvantages for XML Documents
XML documents can be difficult and also expensive to setup. A freelancer for example can sit at his home and at his own pace create, write and format a document or a manuscript using any of the free software available. However, the moment he introduces XML or starts with it, the whole process could get really painful to take the document further.
XML and Unicode Disadvantages
While implementing programs which are multiple in number are incompatible, when XML is split between these it may really turn out into a bad thing. When XML is tied closely to Unicode, the Unicode changes XML’s attributes which might result in something which is totally different from the original.
The XML parsers when used along with the RSS and the component called next cannot disable the external entities. Instead they recognize them as their own which can prove to be a major disadvantage. XML by itself cannot work along with Netscape, which makes it dependent on HTML. In certain instances like this, XML does have disadvantages and cannot be called a super efficient model which is platform independent, and that can be deployed on any operating system. The limitation here is also very basic since it cannot talk to the browsers.
There are a lot of sample codes which belong to HTML and XHTML which contain a doctype, and which points it to a DTD. The common belief is that this actually works, but what very few people don’t realize is that the browsers do not actually retrieve these DTD’s. Whenever the DTD is unavailable for a various number of reasons then the entire application breaks down. This is such a bad phenomenon because the DTD can be unavailable for reasons beyond comprehension, and in some cases and it doesn’t mean that the service itself has to become unavailable.
XML creates an abundant amount of dependency on single factors which can let down the program many times. DTD when available is totally not useful, and an outside program has to be burdened to create a back up system, so users and developers might as well use the outside program from scratch, which has the back up at intermediary levels.
External entities again pose a perennial problem, which again is a major disadvantage for XML. The best way to fix the external entities problems with XML DTD is to not to use them at all, or if you have to use them, then don’t use them on the producer side, and moreover do not attempt to retrieve them on the client’s side.
In case you are writing the specifications for an XML document, do not even mention the specifications for DTD in the vocabulary, and there is also a need for the programs to run their parsers for XML by disabling the external entity resolution. Otherwise the external entities problem will invariably crop up, triggering a series of problems which cannot be solved by the XML environment alone. While layering the specifications it can be considered against the rules to disable or ban certain document types, which is allowed in SOAP.
If your job is to implement the Web application which is based on XML, you may need to configure the parser not to perform the DTD based validations, and also not to try and resolve the external entities. This could be an answer to some of the future problems, so taking precautionary measures is worthwhile. Publishing documents on the web requires the same precautions to be taken by not including the document types.
The document may not be valid like the way XML describes it to be, and some people even believe that the document validation in XML is overrated. Document data types are not known to be very powerful when it comes to validation and it has been forgotten that the document has its own language and grammar which can again not be efficient while getting validated. There is also the problem of other programs not trusting the XML DTD. The doctype in HTML is much different from the doctype in XML. So you may not be able to use the doctype in XML as an indicator, which helps programs understand what type of document it is dealing with.
If there is an application which exists that can handle multiple vocabularies of XML, and also knows to dispatch the respective documents to the concerned handlers by checking the namespace at the root of the element, then you can consider yourself lucky. If the vocabularies are not mentioned in the namespace then you can look for them in the mime type. In some cases the Vocabularies are not present in the name space, nor are they specific to the mime, and then such language is certainly a bad example and will create a lot of problems because you will have to use the root element name.
The XML specifications define three kinds of files processing. The first one is DTD based validations which do not perform or retrieve external entities, and the second one is the DTD based validation which do not perform or retrieve external entities so that the infoset and the reference library can be expanded. The third one is to perform the DTD based validation by retrieving the external entities so that the infoset and the entity reference can be expanded.
The point of having many profiles is so that the application has a choice and it chooses the right one. Character entities are considered unsafe for web applications. It is a disadvantage because there will be a problem with the input and its editor. On the World Wide Web there may be other options available when there is such a problem. The situation need not be so unfortunate because there may be a solution which exists, and there in fact is an input method which can solve the problem with the editor. If the XHTML entities were pre defined then there wouldn’t have been much of these problems. But that is going back in time, and it cannot be changed. As discussed earlier, sometimes for XML its flexibility could turn out to be its biggest disadvantage.
