Did You Know?
We discussed amongst each other this question: Is XML another one of those so called markup languages?
Answer was found on
http://extropia.com/tutorials/xml/what_is_xml.html
XML is far more powerful than HTML. This is because of the "X". XML is "eXtensible". Specifically, rather than providing a set of pre-defined tags, as in the case of HTML, XML specifies the standards with which you can define your own markup languages with their own sets of tags. XML is a meta-markup language which allows you to define an infinite number of markup languages based upon the standards defined by XML.
XML tags, unlike HTML tags, are case sensitive; thus
is a different tag (and will be rendered differently) than
. NOTE: you can use either style, as long as you remain consistent!
XML offers much more complex linking capabilities than HTML; in addition to a linear link between two documents, XML will offer the ability to link documents in complex, bi-directional ways.
HTML documents can be easily "converted" into XML as long as the HTML documents are "well-formed" (meaning that the tags are uniform in case and that all open tags have matching closing tags.
Just as in SGML where the author creates and declares a Document Type Definition for each document, in XML, the header information will declare the associated XML DTD.
Tips
XML requires your document is well-formed.
This means that you cannot create tags that overlap one another. For example, the following is well-formed. Notice how all the tags are properly contained within other tags:
Â
This is bold and italic and this is just italic
While valid HTML has the same requirement, HTML does accept overlapping tags. While rewriting the above example with overlapping tags will usually render as expected in most HTML browsers, it actually creates invalid XML:
Â
This is bold and italic and this is just italic
Â
XML is case-sensitive
If you start a tag in lowercase, you must close the tag in lower-case. For example, while the following is valid HTML, it is invalid XML: .... We choose to define our XML tags entirely in lower-case.
Empty tags must be specified as empty
An empty tag is a tag that does not have a close tag. For example, the IMG, INPUT, BR are empty tags. HTML knows they are empty tags because it is built-into the HTML engine. Since XML may contain arbitrary tags that may not be tested against a DTD (the description of the document) the tags must self-document whether they are containers or not. If you create an empty element in XML, you must provide a "/" at when the tag ends. For example, if you defined an empty IMG tag in XML, you would define it as follows:
In the same regard, all container tags must be closed. For example, in HTML you can create paragraphs simply by specifying
tags sequentially without closing the paragraph with a end
tag. In XML this would be invalid as it would cause your document to be malformed (in XML, the P's have no context and without the end P tag would be assumed to be contained within one another).
All attribute values in XML must be specified in quotes
HTML is fairly flexible in allowing you to omit quotes when specifying attribute values.
In XML, always remember your quotes.
The DataSet Class(#5)
With the introduction of ADO.NET and the DataSet class, an excellent mechanism now exists in the .NET platform for viewing data both in a relational manner and as XML. This is accomplished by using different methods associated with the DataSet such as GetXml() or WriteXml(). Although the GetXml() method simply returns a string representing the XML data, you can use the WriteXml() method to write the XML to several different objects including:
Streams
TextWriters
XmlWriters
Files
If the relational data needs to be converted into a DOM structure for manipulation, you can use the XmlDataDocument class. In fact, converting relational data into a DOM structure is as simple as passing the DataSet into the XmlDataDocument's constructor:
XmlDataDocument doc = new XmlDataDocument(myDataSet);
Â
SQL Server 2000
SQL Server 2000 provides several techniques for converting relational data into XML. When you combine it with the .NET platform, you can per form powerful tasks. First, you can access SQL 2000 data through HTTP rather than ADO.NET. Through using URL, template, or EXPLICIT queries, you can load data directly into an XmlDocument or XmlTextReader class. This is made possible by special functionality integrated into SQL Server 2000 that makes use of the FOR XML keywords. For example, this SQL statement converts data into attribute-centric XML automatically:
SELECT * FROM Customers FOR XML AUTO
If you prefer element-centric XML instead, add the ELEMENTS keyword to the query:
SELECT * FROM Customers FOR XML AUTO
SELECT * FROM Customers FOR XML AUTO, ELEMENTS
If you prefer to use ADO.NET Connection classes to access the database as opposed to going through HTTP, you can use the Command class's ExecuteXmlReader() method. This allows XML data returned from FOR XML queries to be loaded directly into the XmlTextReader class.
SQLXML Managed Classes
New .NET XML classes specific to SQL Server 2000 are available to use when you install the SQL Server 2000 Web Release. Web Release 3 contains the Microsoft.Data.SqlXml namespace, which houses classes such as SqlXmlCommand, SqlXmlParameter, and SqlXmlAdapter that you can use to access the database and view generated XML. For example, this code demonstrates using a few of the SQLXML managed classes along with an annotated XSD schema to generate a custom XML document hierarchy, which is then added to a DataSet:
SqlXmlCommand cmd = new SqlXmlCommand(connString);cmd.CommandText = "Customer";cmd.CommandType = SqlXmlCommandType.XPath;cmd.RootTag = "Customers";cmd.SchemaPath = "customersSchema.xml";//load data setDataSet ds = new DataSet();SqlXmlAdapter adapter = new SqlXmlAdapter(cmd);adapter.Fill(ds);
In my recent second edition of Java and XML, I was able to jam the pages full of things that have been useful in my own Java and XML programming over the last couple of years. I'm happy to report that my reviewers have indicated that many of the things in the book have already made it into their own code; if the book isn't practical, it's not worth much, right? So to try and kick off the official release of the book, I want to offer some basic tips and tricks that will get you going while you're waiting for Java and XML to arrive at your door (that's a not-so-subtle hint, if you weren't paying attention).
Stay vendor-independent
If there's anything that terrifies me, it's the lack of vendor-independence in XML parsing code these days. Although you may be positive you'll never move away from your current parser, I've seen software that costs hundreds of thousands of dollars tossed out overnight. I'd bet on uncertainty, which means coding up vendor-independence whenever possible. To achieve this, you should always try to use JAXP, the Java API for XML Parsing. However, many times you may be limited to using SAX, the Simple API for XML, since it can handle very large documents, and only newer versions of parsers carry the useful 1.1 version of JAXP. If you are forced to work with just SAX, you will still need to find ways to keep vendor-specific code out of your programs. Here's an example of a bad way to get a SAX parser, which is completely dependent on Apache Xerces:
org.xml.sax.XMLReader reader = new org.apache.xerces.parsers.SAXParser();reader.parse(new InputSource("yourXMLURI"));
Not so good, right? Clearly changing a parser implementation, or even the class used, requires changing code, recompiling, retesting...and so on. Here's a much better way to handle this:
org.xml.sax.XMLReader reader =org.xml.sax.helpers.XMLReaderFactory.createXMLReader();
All you have to do to make this work is set a simple system property, org.xml.sax.driver, with the name of the parser class to load. For example, using Xerces again, you would set the value of this property to org.apache.xerces.parsers.SAXParser. You could do this on the command line, with a properties file, or in a variety of other ways, all without needing to change working code to effect the change. In this way your code becomes vendor-indpendent, even when you can't use JAXP.
Â
Use the interface, not the implementation
Another common slip-up I see is when developers are working with interface-based models like the W3C's DOM, the Document Object Model. In this model, each interface has an implementation in the vendor's release. For example, the DOM interface org.w3c.dom.Document is implemented by the Xerces class org.apache.xerces.dom.DocumentImpl. However, all too often, I see code like this:
DocumentImpl doc = new org.apache.xerces.dom.DocumentImpl();
The problem with this is that you aren't working with DOM here; you're working with a specific version of DOM, Apache's version. By making this simple change:
Document doc = new org.apache.xerces.dom.DocumentImpl();
your code can begin to interoperate with other DOM implementations. While many developers see this second approach as "less type-specific," it's always a good idea to stay at the interface level when possible in object-oriented programming. Also consider that when working in XML, interoperability is key; allowing the possibility to work with other DOM implementations may save you hours of work one day in the future.
Â
Customize JDOM with subclasses
Another idea I discuss in a lot of detail in my book is working with custom JDOM subclasses. Many folks ask why JDOM isn't interface-based. I'll avoid that long answer here (it's in the book), but suffice it to say that you can subclass JDOM and get the same effect. Many folks don't know that they can build a JDOM Document with their own subclasses. To do so, you'll need to create your own custom JDOM classes that extend the default Element, Attribute, and so forth. Next, write an implementation of the org.jdom.input.JDOMFactory class. This provides a method for each con structor of each JDOM concrete class. For example, here are the declarations for the element method, which matches the Element class's four constructors:
public Element element(String name, Namespace namespace);public Element element(String name); public Element element(String name, String uri);public Element element(String name, String prefix, String uri);
So, let's say you've got your own subclass of Element, called my.package.MyElement. To ensure that a JDOM tree built using SAXBuilder uses your customized element type, instead of the default type, you would have this implementation of these methods:
public Element element(String name, Namespace namespace) {return new my.pakage.MyElement(name, namespace);}public Element element(String name) {return new my.pakage.MyElement(name);}public Element element(String name, String uri) {return new my.pakage.MyElement(name, uri);}public Element element(String name, String prefix, String uri) {return new my.pakage.MyElement(name, prefix, uri);}
This is simple enough, right? So implement all of these methods, returning your custom types instead of the default JDOM types. Once you've got this done, say in a class called my.package.MyJDOMFactory, you're ready to build your document:
SAXBuilder builder = new SAXBuilder();builder.setFactory(new my.package.MyJDOMFactory());Document customDoc = builder.build("someURI.xml");
In particular, the javax.xml.transform.Templates interface allows for compiling an XSL stylesheet into a binary object and then using it, reusing it, and reusing it again, all without extra processing or memory overhead.
Use the right tool
Finally, I want to urge you to learn more about each of the available Java and XML APIs. Now I'm not saying that just for the sake of knowing and showing off; rather, knowing your tools means knowing how to use them, but also when to use them. Time and time again I see programs written that would have been much easier, sometimes hundreds or thousands of lines shorter, and infintely cleaner, had the developer used a better tool for the job. Here's a few "sub" tips on determining which API is right for the various situations:
Large documents
If you are dealing with huge documents, you need SAX. I know there is a lot of hype around in-memory models like DOM and JDOM supporting this, but it's just not reality yet. If your documents are larger than a meg or so, I'd use SAX. It's sequential, fast, and simple.
Web sites
Unless you are running a highly dynamic Web site (I'd say less than 1 percent of all Web sites are in this category), on-the-fly XSL transformations are a waste of good processing power. You'd be much better off generating your site statically, using Cocoon (statically); XMLC; or even just Apache Xalan. You'll decrease complexity, user load time, and most importantly, headaches.
SOAP or RPC?
For most inter- and intra-application communication, SOAP is overkill. Very rarely will you actually need the complex envelope handling, data mapping, and error processing in everyday Java-to-Java applications. Don't get me wrong--SOAP is great for communicating with non-Java components, UDDI registries, and through firewalls. It's just not the magic bullet that some are saying it is, and is a costly protocol in terms of overhead compared to simpler solutions like XML-RPC.
Beware JAXB
The Java Architecture for Data Binding, or JAXB, is quite the rage these days. However, most people are missing the very small number attached to the release--we're still in the pre-0.5 days, which is awfully early. Now let me be clear: one day JAXB is going to be a great API. However, I'm seeing production code going out using JAXB, and that's just a bad idea. Even if you throw out the significant performance problems with JAXB right now, the API itself is still in flux. You'd be much better off to stick with Castor or Zeus. They're a lot more stable, as well as easier to use.
Simple is best
Use the simplest solution for a task, and watch as you have hours to spare while coworkers debug their more complex, more "glamorous" solutions to simple problems. If you don't need data binding or SOAP or WSDL, don't use them; stick with good old SAX, DOM, or JDOM. If you don't need an XSL transformation, just use a boring little servlet. And if RSS takes care of your problem, don't spend hours working out a Web services solution. Trust me here--the easier the solution, the easier the implementation.
Obviously, this is just a sampling of what's interesting in the Java and XML world these days. I hope it whets your appetite for more information, and if it does, I think that Java and XML, 2nd Edition can give you what you are looking for. No matter how you choose to gather information, though, never stop pursuing new and better ways to code--it makes life fun. So enjoy these tips and tricks, and I'll see you online.
Retrieving information as XML
One point of integration between SQL Server and XML lies in the ability to create an XML file from SQL data. The construction of an XML file is not so complicated that it could not easily be generated using a simple script and an ADO record set. Although this is not a particularly difficult task, it does require developers to produce a different script for each result set they retrieve from the server, or to produce a far more complicated generic script. The SELECT statement now has a new FOR XML clause.
A look at the syntax for this clause shows the following:
[ FOR { XML { RAW | AUTO | EXPLICIT }[ , XMLDATA ][ , ELEMENTS ][ , BINARY BASE64 ] } ]
The XML mode of the FOR XML clause is indicated by one of the three values: RAW, AUTO, or EXPLICIT. The mode determines the shape and schema of the resulting XML. Let's take a closer look at each option with the following examples.
RAW example
We execute the following SQL Statement:
SET ROWCOUNT 3SELECT Orders.OrderID, Orders.OrderDate, ProductIDFROM Orders, [Order Details]WHERE Orders.OrderID = [Order Details].OrderIDORDER BY Orders.OrderIDFOR XML RAW
It yields the following result:
Â
AUTO example
We execute the following SQL Statement:
Want to limit the result to 3 records.
SET ROWCOUNT 3SELECT Orders.OrderID, Orders.OrderDate, ProductIDFROM Orders, [Order Details]WHERE Orders.OrderID = [Order Details].OrderIDORDER BY Orders.OrderIDFOR XML AUTO
It yields the following result:
Â
Â
EXPLICIT example
Explicit mode provides the query writer with complete control of the XML being generated. The control comes with a hefty price tag: Each query must be written so that the XML information accompanies each part of the SQL Statement.
The complex syntax for this is beyond the scope of this article. The [ , XMLDATA ] [ , ELEMENTS ] [ , BINARY BASE64 ] indicates that these are optional parameters.
Optional elements
The examples provide a closer look at the inner workings of each setting. Now we'll take a closer look at the optional elements of the FOR XML statement, XMLDATA
If you specify this option, the XML-Data schema will be included in the result set. Here is the SQL statement:
SET ROWCOUNT 3SELECT Orders.OrderID, Orders.OrderDate, ProductIDFROM Orders, [Order Details]WHERE Orders.OrderID = [Order Details].OrderIDORDER BY Orders.OrderIDFOR XML AUTO, XMLDATA
Â
ELEMENTS
The ELEMENTS option dictates that the columns should be returned as sub-elements, rather than attributes. You can only use this option if you use the AUTO mode.
BINARY BASE64
By using this option you are indicating that you want binary data to be represented in base64-encoded format.
There are many guidelines for using the XML clause? so many that you would do best to refer to the SQL Books online.
How to use SQLXML 3.0 and its managed classes in .Net to extend Web services' functionality with SQL Server
With SQLXML 3.0, you can use SQL Server to expose Web services using SOAP messaging. Using SOAP enables your applications to act as a client of the Web services exposed by SQL Server. SQLXML's Web services support the execution of stored procedures, user-defined functions, and templates. Another key feature in SQLXML 3.0 is the managed classes that are exposed within the .Net framework. These classes extend the ability to access XML data from Microsoft SQL Server from the .Net environment. In this article, you will learn how to expose a stored procedure as a Web service and how to access the Web service. You will also learn how to use the SQMLXML managed classes to execute SQL queries from .Net applications.
I've stored a series of images in an XML document by assigning the file path of each image file to an attribute (Source) of an empty element (IMAGE). The following is an example:
Â
Â
How can I display these images using XSLT?
To display an image, you can use the xsl:attribute XSLT element in the style sheet, as in this example:
Â
These lines will output an HTML IMG element, assigning to the SRC attribute of that element the value stored in the Source attribute of the IMAGE element in the XML document. This will cause the browser to display the image.
How do I add an attribute to a literal result element if I want to derive the value of the attribute from an element or attribute in the XML document?
If you want to obtain the attribute's value from the XML file, you need to use the xsl:attribute element. For example, consider an XML document with the following document element, in which the COLORCODE elements indicate the color that should be used for displaying each book's title:
redgreenblue
You could use the xsl:template element as follows to insert a STYLE attribute into each literal result SPAN element that is copied to the output. The color part of each attribute's value is obtained from the content of the corresponding COLORCODE element in the XML document (red, green, or blue):
color:
The result of this example would be to display the first book title in red, the second in green, and the third in blue. You can add one or more xsl:attribute elements to a literal result element in addition to adding attributes with known values to the literal result element's start-tag. The xsl:attribute element or elements must come before any other child elements or any character data belonging to the literal result element.
My problem is that when I open a cascading style sheet in Notepad and save it with the .css extension, there is no way I can later reopen it. Right now I am saving two copies of the CSS file, one with the .css extension and one with the .txt extension (so I can reopen it).
Remember that there are more ways to open a file in Notepad than by double-clicking it! To open a file in Notepad that has an extension other than .txt, you need to run the Notepad program (from the Start menu in Windows) and use the Open command on Notepad's File menu. Or, once Notepad is running, you can drag a file from Windows Explorer and drop it on the Notepad window. If a file doesn't have the .txt extension, you can't open it by double-clicking because the extension isn't registered to be opened by Notepad.
In my XML document, the line gives this error: "The XML page cannot be displayed. Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later."
The problem is that there should be no spaces in the expression xml-stylesheet (although the font used in XML Step by Step makes it look like there might be spaces).
My problem is that I can't create an external DTD with Notepad. If I try it I get for example: Tom.dtd.txt.?
When you save the file, in the Save As dialog box, enclose the entire name in quotes, like this: "Tom.dtd"
That way, Notepad won't add the .txt extension.
I used WordPad to create an XML file, but when I opened it in Internet Explorer, I got the following error message:
 Invalid at the top level of the document. Line 1, Position 1
{\rtf1\ansi\ansicpg1252\deff0\deflang1033 {\fonttbl{\f0\fmodern\fprq1\fch
arset0 Courier New;}}
What should I have to do?
If you use a word processor, such as Microsoft WordPad or Word, to create an XML document or other source file (for example, a style sheet or XML schema), you must explicitly save the file in a plain text format. If you save the file in the word processor's default format, the file will contain extraneous characters that will make it unsuitable for processing in a browser or other XML program.
However, rather than using a word processor, it's usually easiest to use a text editor, which automatically saves a file in a plain text format. The most common text editor you can use is Notepad, which comes with Windows. Or you can use a standard programming editor, which also creates plain text files.
What I would like to know is, what's the best software to use when trying to write XML documents? Currently I am using Microsoft's Notepad, which is easy to use.
A You can use any text or programming editor that creates plain text files to create XML documents and other source files. Notepad is adequate, but it lacks two features that make writing XML much easier: AutoTabbing (the next line is indented automatically when you press Enter) and the ability to select and indent or de-indent multiple lines. My current favorite XML editor is the programming editor included with Microsoft Visual Studio.
I can't get it to work in a table. Take, for example, the following XML document:
Mark Twain Microsoft Press
In the HTML file I would like to have something like this:
Book Inventory
Title
Author
Publisher
Â
Â
Â
I would like to have the PUBLISHER name in the table (for example, "Microsoft Press") serve as a hyperlink to the associated home page (for example,
http://www.microsoft.com/mspress/). How can I do that?
In the XML document, store the publisher information in two separate elements, one for the publisher's name and the other for the publisher's URL, as in the following XML document:
Mark TwainMicrosoft Press
http://www.microsoft.com/mspress/
Then, in the HTML file, bind an A element to the publisher URL element to create the hyperlink, and bind a SPAN element to the publisher name element to specify the hyperlink text. For instance, the following HTML file would display the publisher information given in the XML example above:
Book Inventory
Title
Author
Publisher
Â
Â
Â
