Namespaces As discussed earlier, XML allows you to create your own languages. However, what if someone else has developed a schema that you want to use? There is the chance that element names from this other schema will conflict with yours. XML has a solution for this: namespaces. Namespaces allow you to make your elements globally unique. It does this by attaching your element names to a Universal Resource Identifier (URI). A Uniform Resource Locator (URL) is an example of a URI, as is a Uniform Resource Name (URN). Even if you use an extremely common element name in your document, such as name, you can make it globally unique by specifying a URI that you control. XSQL uses a URN—<oracle-xsql>—for its namespace. You may have noticed it in the examples: <page connection=”demo” xmlns:xsql=”urn:oracle-xsql”> The <xmlns:xsql> attribute signifies that some children elements of the page ele- ment will belong to the XSQL namespace. Namespaces can overlap—in fact, that’s the whole point. The following XSQL example shows this. This page uses both the XSQL namespace and the Mike namespace. <?xml version=”1.0”?> <page connection=”demo” xmlns:xsql=”urn:oracle-xsql” xmlns:mike=””> <xsql:query> select * from emp where ename=’SMITH’   </xsql:query> <mike:mikeNode> Value </mike:mikeNode> </page> The output of this XSQL is shown above. Notice that the <xmlns:mike> attribute is preserved but the <xmlns:xsql> namespace isn’t. In the output, no member of the XSQL  namespace  is  present.  The  <xsql:query>  element  was  replaced  with  the results of the query. Because there are no members of the namespace in the document, the XSQL page processor removes the attribute. Schemas We  spoke  earlier  about  how  XML  allows  you  to  create  your  own  languages.  These languages are formally known as schemas. A schema is a definition of how elements in your  XML  should  relate  to  one  another,  what  attributes  are  appropriate,  and  what values are appropriate for nonempty elements. You can program very successfully in XSQL without ever creating your own schema. At the least, it’s important to be con- versant about schemas. The XML documents that you have seen so far are very simple, but XML can be very complex. The purpose of a schema is to rein in that complexity. This makes it easier for applications  to  be  able  to  consume  the  XML—they  know  what  they  are  expecting. Introducing Oracle XSQL 21 271209 Ch01.F  12/9/02  2:00 PM  Page 21