29+ Advanced XML Interview Questions (ANSWERED) Web Devs Must Know

XML is not a database. It was never meant to be a database. It is never going to be a database. Relational databases are proven technology with more than 20 years of implementation experience. They are solid, stable, useful products. They are not going away. XML is a very useful technology for moving data between different databases or between databases and other programs. However, it is not itself a database. Don't use it like one.

You can build a DBMS with a DOM/XPath interface but to get ACID properties or scale to large data sets you need to implement a DBMS engine and a data format with indexes, logging and other artifacts of a DBMS - which (by definition) makes it something other than XML.

If you use an appropriate class or library, they will do the escaping for you. Many XML issues are caused by string concatenation.

1. Always
   • Escape < as < unless < is starting a <tag/>
   • Escape & as & unless & is starting an &entity;

2. Attribute Values
   • attr=" 'Single quotes' are ok within double quotes."
   • attr=' "Double quotes" are ok within single quotes.'
   • Escape " as " and ' as ' otherwise.

3. Comments, CDATA, and Processing Instructions
   • <!-- Within comments --> nothing has to be escaped but no -- strings are allowed.
   • <![CDATA[ Within CDATA ]]> nothing has to be escaped, but no ]]> strings are allowed.
   • <?PITarget Within PIs ?> nothing has to be escaped, but no ?> strings are allowed.

4. Esoterica
   • Escape ]]> as ]]> unless ]]> is ending a CDATA section. This rule applies to character data in general – even outside a CDATA section.

XPath is an important and core component of XSLT standard. It is used to traverse the elements and attributes in an XML document.

XPath is a W3C recommendation. XPath provides different types of expressions to retrieve relevant information from the XML document. It is syntax for defining parts of an XML document.

Before XSLT, first we should learn about XSL. XSL stands for EXtensible Stylesheet Language. It is a styling language for XML just like CSS is a styling language for HTML. XSLT stands for XSL Transformation. It is used to transform XML documents into other formats (like transforming XML into HTML).

In HTML documents, tags are predefined but in XML documents, tags are not predefined. World Wide Web Consortium (W3C) developed XSL to understand and style an XML document, which can act as XML based Stylesheet Language. An XSL document specifies how a browser should render an XML document.

The XSLT stylesheet is written in XML format. It is used to define the transformation rules to be applied on the target XML document. The XSLT processor takes the XSLT stylesheet and applies the transformation rules on the target XML document and then it generates a formatted document in the form of XML, HTML, or text format. At the end it is used by XSLT formatter to generate the actual output and displayed on the end-user.

XSD (XML Schema Definition) specifies how to formally describe the elements in an Extensible Markup Language (XML) document. XML was designed to describe data.

Actually the XSD is XML itself. Its purpose is to validate the structure of another XML document. The XSD is not mandatory for any XML, but it assures that the XML could be used for some particular purposes. The XML is only containing data in suitable format and structure.

Differences:

• XSD is based and written on XML.
• XSD defines elements and structures that can appear in the document, while XML does not.
• XSD ensures that the data is properly interpreted, while XML does not.
• An XSD document is validated as XML, but the opposite may not always be true.
• XSD is better at catching errors than XML.

JSON Pro:

• Simple syntax, which results in less "markup" overhead compared to XML.
• Easy to use with JavaScript as the markup is a subset of JS object literal notation and has the same basic data types as JavaScript.
• JSON Schema for description and datatype and structure validation

• JsonPath for extracting information in deeply nested structures JSON Con:

• Simple syntax, only a handful of different data types are supported.

• No support for comments.

XML Pro:

• Generalized markup; it is possible to create "dialects" for any kind of purpose
• XML deals remarkably well with the full richness of unstructured data CDATA
• XML Schema for datatype, structure validation. Makes it also possible to create new datatypes
• XSLT for transformation into different output formats
• XPath/XQuery for extracting information in deeply nested structures
• built in support for namespaces

XML Con:

• Relatively wordy compared to JSON (results in more data for the same amount of information).
• XML presents a 21% overhead over JSON
• Requires some reasonable more time to compress.

Consider:

<university>
    <student>
        <name>
            John Niel             //---> I can also use an Integer,not good
        </name>
        <year>
            2000                 //---> I can also use a string,not good
        </year>
    </student>
</university>

Use:

/Employees/Employee[@id='4']

or

//Employee[@id='4']

// can be very slow because it searches the entire document for matching nodes. If the structure of the documents you're working with is going to be consistent, you are probably best off using a full path.

There is a difference, yes.

• XML that adheres to the XML standard is considered well formed,
• while xml that adheres to a DTD is considered valid.

Well-formedness is a prerequisite for validity. Validity refers to semantics, well-formedness refers to syntax.

Use this XSLT:

<?xml version = "1.0" encoding = "UTF-8"?>  
<!-- xsl stylesheet declaration with xsl namespace:   
Namespace tells the xlst processor about which   
element is to be processed and which is used for output purpose only   
-->   
<xsl:stylesheet version = "1.0"   
xmlns:xsl = "http://www.w3.org/1999/XSL/Transform">     
<!-- xsl template declaration:    
template tells the xlst processor about the section of xml   
document which is to be formatted. It takes an XPath expression.   
In our case, it is matching document root element and will   
tell processor to process the entire document with this template.   
-->   
   <xsl:template match = "/">   
      <!-- HTML tags   
         Used for formatting purpose. Processor will skip them and browser   
            will simply render them.   
      -->   
      <html>   
         <body>  
            <h2>Employee</h2>   
            <table border = "1">   
               <tr bgcolor = "#9acd32">   
                  <th>ID</th>   
                  <th>First Name</th>   
                  <th>Last Name</th>   
                  <th>Nick Name</th>   
                  <th>Salary</th>   
               </tr>   
               <!-- for-each processing instruction   
               Looks for each element matching the XPath expression   
               -->   
              <xsl:for-each select="class/employee">   
                  <tr>   
                     <td>   
                        <!-- value-of processing instruction   
                        process the value of the element matching the XPath expression   
                        -->   
                        <xsl:value-of select = "@id"/>   
                     </td>   
                     <td><xsl:value-of select = "firstname"/></td>   
                     <td><xsl:value-of select = "lastname"/></td>   
                     <td><xsl:value-of select = "nickname"/></td>   
                     <td><xsl:value-of select = "salary"/></td>     
                  </tr>   
               </xsl:for-each>   
            </table>   
         </body>   
      </html>   
   </xsl:template>    
</xsl:stylesheet>  

To apply this XSLT to XML update XML document with the following xml-stylesheet tag:

<?xml version = "1.0"?>   
<?xml-stylesheet type = "text/xsl" href = "employee.xsl"?>   
<class>   
...   
</class>  

A list of advantages of using XSLT:

• XSLT provides an easy way to merge XML data into presentation because it applies user defined transformations to an XML document and the output can be HTML, XML, or any other structured document.
• XSLT provides Xpath to locate elements/attribute within an XML document. So it is more convenient way to traverse an XML document rather than a traditional way, by using scripting language.
• XSLT is template based. So it is more resilient to changes in documents than low level DOM and SAX.
• By using XML and XSLT, the application UI script will look clean and will be easier to maintain.
• XSLT templates are based on XPath pattern which is very powerful in terms of performance to process the XML document.
• XSLT can be used as a validation language as it uses tree-pattern-matching approach.
• You can change the output simply modifying the transformations in XSL files.

A CDATA section is "a section of element content that is marked for the parser to interpret as only character data, not markup." The data contained therein will not be parsed as XML, and as such does not need to be valid XML or can contain elements that may appear to be XML but are not.

<![CDATA[
Within this Character Data block I can
use double dashes as much as I want (along with <, &, ', and ")
*and* %MyParamEntity; will be expanded to the text
"Has been expanded" ... however, I can't use
the CEND sequence. If I need to use CEND I must escape one of the
brackets or the greater-than sign using concatenated CDATA sections.
]]>

Or:

<description>An example of escaped CENDs</description>
<!-- This text contains a CEND ]]> -->
<!-- In this first case we put the ]] at the end of the first CDATA block
     and the > in the second CDATA block -->
<data><![CDATA[This text contains a CEND ]]]]><![CDATA[>]]></data>
<!-- In this second case we put a ] at the end of the first CDATA block
     and the ]> in the second CDATA block -->
<alternative><![CDATA[This text contains a CEND ]]]><![CDATA[]>]]></alternative>

It defines an XML Namespace.

Basically, every element (or attribute) in XML belongs to a namespace, a way of "qualifying" the name of the element.

Imagine you and I both invent our own XML. You invent XML to describe people, I invent mine to describe cities. Both of us include an element called name. Yours refers to the person’s name, and mine to the city name—OK, it’s a little bit contrived.

<person>
    <name>Rob</name>
    <age>37</age>
    <homecity>
        <name>London</name>
        <lat>123.000</lat>
        <long>0.00</long>
    </homecity>
</person>

If our two XMLs were combined into a single document, how would we tell the two names apart? As you can see above, there are two name elements, but they both have different meanings.

The answer is that you and I would both assign a namespace to our XML, which we would make unique:

<personxml:person xmlns:personxml="http://www.your.example.com/xml/person"
                  xmlns:cityxml="http://www.my.example.com/xml/cities">
    <personxml:name>Rob</personxml:name>
    <personxml:age>37</personxml:age>
    <cityxml:homecity>
        <cityxml:name>London</cityxml:name>
        <cityxml:lat>123.000</cityxml:lat>
        <cityxml:long>0.00</cityxml:long>
    </cityxml:homecity>
</personxml:person>

Now we’ve fully qualified our XML, there is no ambiguity as to what each name element means. All of the tags that start with personxml: are tags belonging to your XML, all the ones that start with cityxml: are mine.

Processing Instruction is defined in the XML standard, XML 1.0 Recommendation. The definition says: "Processing instructions (PIs) allow documents to contain instructions for applications… PIs are not part of the document's character data, but MUST be passed through to the application."

Following is the syntax of PI:

<?target instructions?>

And some examples:

<?display table-view?>
<?sort alpha-ascending?>
<?textinfo whitespace is allowed ?>
<?elementnames <fred>, <bert>, <harry> ?>

In the real world PIs are seldom used with a few common exceptions. The PI is the official method for an XML document to link to a stylesheet, and Microsoft uses PIs in MS Office 2003 to make it easy for MS Word and MS Excel documents to be identified when saved as XML:

<?xml-stylesheet href="mystyle.css" type="text/css"?>

Think of XML as not a sequence of characters but a sequence of bytes. Imagine the system receiving the XML sees the bytes 195, 162. How does it know what characters these are? In order for the system to interpret those bytes as actual characters (and so display them or convert them to another encoding), it needs to know the encoding used in the XML.

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

Use:

/bla/a[contains(@prop,'Foo')]

Favor JSON over XML when all of these are true:

• Messages don't need to be validated, or validating their deserialization is simple
• You're not transforming messages, or transforming their deserialization is simple
• Your messages are mostly data, not marked-up text
• The messaging endpoints have good JSON tools

Favor XML over JSON when any of these is true:

• You need message validation
• You're using XSLT
• Your messages include a lot of marked-up text
• You need to interoperate with environments that don't support JSON
• You need to process the data on the client, and you can leverage XSL for that. Chances are the XML + XSL chain will work faster than JSON + JavaScript especially for big chunks of data.
• One good case is to convert the data into an HTML snippet
• Various legacy cases:
• There is an existing XML service, and it is a hassle to rewrite it with JSON for some reasons.
• You have to post this data back as XML after some light processing using user's input.

Short and sweet:

//*[@foo]

With [@attributeName] you get all nodes which have that attribute.