So, with all that said, in this chapter we’ll look at: ❑ What XML is ❑ What other technologies are closely tied to XML I mentioned a bit ago that XML is usually not a good way to store data, but there are exceptions. One way that XML is being utilized for data storage is for archival purposes. XML compresses very well, and it is in a very open kind of format that will be well understood for many years to come — if not forever. Compare that to, say, just taking a SQL Server 2008 backup. A decade from now when you need to restore some old data to review archival information, you may very well not have a SQL Server installa- tion that can handle such an old backup file, but odds are very strong indeed that you’ll have something around that can both decompress (assuming you used a mainstream compression library such as ZIP) and read your data. Very handy for such “deep” archives. XML Basics There are tons and tons of books out there on XML (for example, Wrox’s Professional XML, by Evjen et al). Given how full this book already is, my first inclination was to shy away from adding too much information about XML itself, and assume that you already knew something about XML. I have, how- ever, come to realize that even all these years after XML hit the mainstream, I continue to know an awful lot of database people who think that XML “is just some Web technology,” and, therefore, have spent zero time on it — they couldn’t be more wrong. XML is first and foremost an information technology. It is not a Web-specific technology at all. Instead, it just tends to be thought of that way (usually by people who don’t understand XML) for several reasons — such as: ❑ XML is a markup language, and looks a heck of a lot like HTML to the untrained eye. ❑ XML is often easily transformed into HTML. As such, it has become a popular way to keep the information part of a page, with a final transformation into HTML only on request — a separate transformation can take place based on criteria (such as what browser is asking for the information). ❑ One of the first widely used products to support XML was Microsoft’s Internet Explorer. ❑ The Internet is quite often used as a way to exchange information, and that’s something that XML is ideally suited for. Like HTML, XML is a text-based markup language. Indeed, they are both derived from the same origi- nal language, called SGML. SGML has been around for much longer than the Internet (at least what we think of as the Internet today), and is most often used in the printing industry or in government related documentation. Simply put, the “S” in SGML doesn’t stand for simple (for the curious, SGML stands for “standard generalized markup language”) — SGML is anything but intuitive and is actually a downright pain to learn. (I can only read about 35 percent of SGML documents that I’ve seen. I have, however, been able to achieve a full 100 percent nausea rate when reading any SGML.) XML, on the other hand, tends to be reasonably easy to decipher. 474 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 474 So, this might have you asking the question: “Great — where can I get a listing of XML tags?” Well, you can’t — at least, not in the sense that you’re thinking when you ask the question. XML has very few tags that are actually part of the language. Instead, it provides ways of defining your own tags and utilizing tags defined by others (such as the industry groups I mentioned earlier in the chap- ter). XML is largely about flexibility — which includes the ability for you to set your own rules for your XML through the use of either an XML schema document or the older Document Type Defini- tion (DTD). An XML document has very few rules placed on it just because it happens to be XML. The biggie is that it must be what is called well formed. We’ll look into what well formed means shortly. Now, just because an XML document meets the criteria of being well formed doesn’t mean that it would be classified as being valid. Valid XML must not only be well formed, but must also live up to any restrictions placed on the XML document by XML schemas or DTDs that document references. We will briefly examine DTDs and XML schemas later on in this chapter. XML can also be transformed. The short rendition of what this means is that it is relatively easy for you to turn XML into a completely different XML representation or even a non-XML format. One of the most common uses for this is to transform XML into HTML for rendering on the Web. The need for this trans- formation presents us with our first mini-opportunity to compare and contrast HTML with XML. In the simplest terms, XML is about information, and HTML is about presentation. The information stored in XML is denoted through the use of what are called elements and attributes. Elements are usually created through the use of an opening and a closing tag (there’s an exception, but we’ll see that later) and are identified with a case-sensitive name (no spaces allowed). Attributes are items that further describe elements and are embedded in the element’s start tag. Attribute values must be in matched single or double quotes. Parts of an XML Document Well, a few of the names have already flown by, but it makes sense, before we get too deep into things, to stop and create something of a glossary of terms that we’re going to be utilizing while talking about XML documents. What we’re really going to be doing here is providing a listing of all the major parts of an XML docu- ment that you will run into, as shown in Figure 16-1. Many of the parts of the document are optional, though a few are not. In some cases, having one thing means that you have to have another. In other cases, the parts of the document are relatively independent of each other. We will take things in something of a hierarchical approach (things that belong “inside” of something will be listed after whatever they belong inside of), and where it makes sense, in the order you’ll come across them in a given XML document. The Document The document encompasses everything from the very first character to the last. When we refer to an XML document, we are referring to both the structure and the content of that particular XML document. 475 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 475 Figure 16-1 Declaration The declaration is technically optional, but, as a practical matter, should always be included. If it exists, it must be the very first thing in the document. Nothing can be before the declaration, not even white space (spaces, carriage returns, tabs, whatever) — nothing. Attribute Attribute Attribute Closing Tag Closing Tag Opening Tag Opening Tag Element Content (Possibly Including Other Elements) Declaration Attribute Closing Tag Opening Tag Element Content (Possibly Including Other Elements) The Declaration is optional. If it exists, it must be first (even before white space) and follow a specific format. An Attribute is defined within the Opening tag of an element. There is one and only one “root” element. All other elements must exist within the boundaries of that root element. Document Closing tag: every Opening tag must either be self-closing or have a closing tag. Co ntent between the opening and closing tags of an element is considered to be the “content” of that element. This can include raw text or other elements. 476 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 476 The declaration is made with a special tag that begins with a question mark (which indicates that this tag is a preprocessor directive) and the xml moniker: <?xml version=”1.0”?> The declaration has one required attribute (something that further describes the element) — the version. In the preceding example, we’ve declared that this is an XML document and also that it is to comply with version 1.0 (as of this writing, there is also a version 1.1, though you’ll want to stick with 1.0 wher- ever possible) of the XML specification. The declaration can optionally have one additional attribute — this one is called encoding, and it describes the nature of the character set this XML document utilizes. XML can handle a few different character sets, most notably UTF-16 and UTF-8. UTF-16 is essentially the Unicode specification, which is a 16-bit encoding specification that allows for most characters in use in the world today. The default encoding method is UTF-8, which is backward compatible to the older ASCII specification. A full decla- ration would look like this: <?xml version=’1.0’ encoding=’UTF-8’?> Elements that start with the letters xml are strictly forbidden by the specification — instead, they are reserved for future expansion of the language. Elements Elements serve as a piece of glue to hold together descriptive information about something — it hon- estly could be anything. Elements define a clear start and end point for your descriptive information. Usually, elements exist in matched pairs of tags known as an opening tag and a closing tag. Option- ally, however, the opening tag can be self-closing — essentially defining what is known as an empty element. The structure for an XML element looks pretty much as HTML tags do. An opening tag will begin with an opening angle bracket ( <), contain a name and possibly some attributes, and then a closing angle bracket ( >): <ATagForANormalElement > The exception to the rule is if the element is self-closing, in which case the closing angle bracket of the opening tag is preceded with a forward slash (/): <AselfClosingElement/> Closing tags will look exactly like the opening tag (case sensitive), but start with a slash (/) before the name of the element it’s closing: <ATagForANormalElement > <== Opening Tag Some data or whatever can go in here. We’re still going strong with our data. </ATagForANormalElement > <== Closing Tag 477 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 477 Elements can also contain attributes (which we’ll look at shortly) as part of the opening (but not the clos- ing) tag for the element. Finally, elements can contain other elements, but, if they do, the inner element must be closed before closing the outer element: <OuterElement> <InnerElement> </InnerElement> </OuterElement> We will come back to elements shortly when we look at what it means to be well formed. Nodes When you map out the hierarchies that naturally form in an XML document, they wind up taking on the familiar tree model that you see in just about any hierarchical relationship, illustrated in Figure 16-2. Each intersection point in the tree is referred to as a node. Figure 16-2 The contents of an XML document can be navigated based on node levels and the values in the attrib- utes and elements of particular nodes. The “Root” Node Perhaps one of the most common points of confusion in XML documents is over what is called the root node. Every XML document must have exactly one (no more, no less) root node. The root node is an ele- ment that contains any other elements in the document (if there are any). You can think of the root node as being the unification point that ties all the nodes below it together and gives them structure within Root Node. There must be one and only one. It is often called “root”, but doesn’t have to be. Another Node. A child of the one above. Example: Line Items (Orders have line items) Another Node. A child of the one above. Example: Orders (Customers have Orders) A secondary Node. This is the immediate child of the root node. There can be zero, one, or many of these. Example: Customers 478 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 478 the scope of any particular XML document. So, what’s all the confusion about? Well, it usually falls into two camps: Those that don’t know they need to have a singular root node (which you now know), and those who don’t understand how root nodes are named (which you will understand in a moment). Because the general statement is usually “You must have a root node,” people usually interpret that to mean that they must have a node that is called root. Indeed, you’ll occasionally find XML documents that do have a root node named Root (or root or ROOT). The reality, however, is that root nodes follow the exact same naming scheme as any other element with only one exception — the name must be unique throughout the document. That is, no other element in the entire document can have the same name as the root. Attributes Attributes exist only within the context of an element. They are implemented as a way of further describing an element, and are placed within the boundaries of the opening tag for the element: <SomeElement MyFirstAttribute=”Hi There” MySecondAttribute=”25”> Optionally, some other XML </SomeElement> Regardless of the data type of the information in the value for the attribute, the value must be enclosed in either single or double quotes. By default, XML documents have no concept of data type. We will investigate ways of describing the rules of individual document applications later in this chapter. At that time, we’ll see that there are some ways of ensuring data type — it’s just that you set the rules for it; XML does not do that by itself. No Defects — Being Well Formed The part of the rules that define how XML must look — that is, what elements are okay, how they are defined, what parts they have — is about whether an XML document is well formed or not. Actually, all SGML-based languages have something of the concept of being well formed. Heck, even HTML has something of the concept of being well formed — it’s just that it has been largely lost in the fact that HTML is naturally more forgiving and that browsers ignore many errors. If you’re used to HTML at all, then you’ve seen some pretty sloppy stuff as far as a tag-based language goes. XML has much stricter rules about what is and isn’t OK. The short rendition looks like this: ❑ Every XML document must have a unique “root” node. ❑ Every tag must have a matching (case sensitive) closing tag unless the opening tag is self-closing. The existence of a root node is a key difference between an XML document and an XML fragment. Often, when extracting things from SQL Server, you’ll be extracting little pieces of XML that belong to a large whole. We refer to these as XML frag- ments. Because an XML fragment is not supposed to be the whole document, we don’t expect these to have a root node. 479 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 479 ❑ Tags cannot straddle other tags. ❑ You can’t use restricted characters for anything other than what they indicate to the XML parser. If you need to represent any of these special characters, then you need to use an escape sequence (which will be translated back to the character you requested). It’s worth noting that HTML documents are more consistently “well formed” than in years past. Around the time that XML came out, a specification for XHTML was also developed — that is, HTML that is also valid XML. Many developers today try and make their HTML meet XHTML standards with the result being, at the least, much more well formed HTML. The following is an example of a document that is well formed: <?xml version=”1.0” encoding=”UTF-8”?> <ThisCouldBeCalledAnything> <AnElement> <AnotherElement AnAttribute=”Some Value”> <AselfClosingElement AnAttributeThatNeedsASpecialCharacter=”Fred&quot;s flicks”/> </AnotherElement> </AnElement> </ThisCouldBeCalledAnything> Notice that we didn’t need to have a closing tag at all for the declaration. That’s because the declaration is a preprocessor directive — not an element. Essentially, it is telling the XML parser some things it needs to know before the parser can get down to the real business of dealing with our XML. So, this has been an extremely abbreviated version of what’s required for your XML document to be con- sidered to be well formed, but it pretty much covers the basics for the limited scope of our XML cover- age in this book. Understanding these concepts is going to be absolutely vital to your survival (well, comprehension at least) in the rest of the chapter. The example that is covered next should reinforce things for you, but, if after looking at the XML example, you find you’re still confused, then read the preceding text again or check out Professional XML or some other XML book. Your sanity depends on knowing this stuff before you move on to the styling and schema issues at the end of the chapter. An XML Example OK — if there’s one continuing theme throughout this book, it’s got to be that I don’t like explaining things without tossing out an example or two. As I’ve said earlier, this isn’t an XML book, so I’m not going to get carried away with my examples here, but let’s at least take a look at what we’re talking about. Throughout the remainder of this chapter, you’re going to find that life is an awful lot easier if you have some sort of XML editing tool (Microsoft offers a free one called XML Notepad. I’ve tended toward a product called XMLSpy, which was one of the earliest full function XML editors). Because XML is text based, you can easily open and edit XML documents in Notepad — the problem is that you’re not going to get any error checking. How are you going to know that your document is well formed? Sure, you can look it over if it’s just a few lines, but get to a complete document or a style sheet document (we will dis- cuss transformations later in the chapter), and life will quickly become very difficult. 480 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 480 As a side note, you can perform a rather quick and dirty check to see whether your XML is well formed or not by opening the document in Microsoft’s Internet Explorer — it will complain to you if the docu- ment is not well formed. For this example, we’re going to look at an XML representation of what some of our AdventureWorks2008 data might look like. In this case, I’m going to take a look at some order information. We’re going to start with just a few things and grow from there. First, we know that we need a root node for any XML document that we’re going to have. The root node can be called anything we want, as long as it is unique within our document. A common way of dealing with this is to call the root root. Another common example would be to call it something representative of what the particular XML document is all about. For our purposes, we’ll start off with something hyper-simple, and just use root: <root> </root> Just that quickly we’ve created our first well-formed XML document. Notice that it didn’t include the <?xml> tag that we saw in the earlier illustration. We could have put that in, but it’s actually an optional item. The only restriction related to it is that, if you include it, it must be first. For best practice reasons as well as clearness, we’ll go ahead and add it: <?xml version=”1.0” encoding=”UTF-8”?> <root> </root> Actually, by the rules of XML, any tag starting with <?xml> is considered to be a reserved tag — that is, you shouldn’t name your tags that, as they are reserved for current or future use of the W3C as XML goes into future versions. So, moving on, we have our first well-formed XML document. Unfortunately, this document is about as plain as it can get — it doesn’t really tell us anything. Well, for our example, we’re working on describ- ing order information, so we might want to start putting in some information that is descriptive of an order. Let’s start with a SalesOrderHeader tag: <?xml version=”1.0” encoding=”UTF-8”?> <root> <SalesOrderHeader/> </root> OK — so this is getting monotonous — isn’t it? We now know that we have one order in our XML docu- ment, but we still don’t know anything about it. Let’s expand on it some by adding a few attributes: <?xml version=”1.0” encoding=”UTF-8”?> <root> <SalesOrderHeader CustomerID=”510” SalesOrderID=”43663” OrderDate=”2001-07-01T00:00:00” /> </root> 481 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 481 Well, it doesn’t really take a rocket scientist to be able to discern the basics about our order at this point: ❑ The customer’s ID number is 510. ❑ The order ID number was 43663. ❑ The order was placed on July 1, 2001. Basically, as we have things, it equates to a row in the SalesOrderHeader table in AdventureWorks2008 in SQL Server. If the customer had several orders, it might look something like: <?xml version=”1.0” encoding=”UTF-8”?> <root> <SalesOrderHeader CustomerID=”510” SalesOrderID=”43663” OrderDate=”2001-07-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”44281” OrderDate=”2001-10-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”45040” OrderDate=”2002-01-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”46606” OrderDate=”2002-07-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”47661” OrderDate=”2002-10-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”49824” OrderDate=”2003-04-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”55285” OrderDate=”2003-10-01T00:00:00”/> <SalesOrderHeader CustomerID=”510” SalesOrderID=”61178” OrderDate=”2004-01-01T00:00:00”/> </root> While this is a perfectly legal — and even well formed — example of XML, it doesn’t really represent the hierarchy of the data as we might wish. We might, for example, wish to build our XML a little differ- ently, and represent the notion that customers are usually considered to be higher in the hierarchical chain (they are the “parent” to orders if you will). We could represent this by changing the way we express customers. Instead of an attribute, we could make it an element in its own right — including having its own attributes — and nest that particular customer’s orders inside the customer element: <?xml version=”1.0” encoding=”UTF-8”?> <root> <Customer CustomerID=”510” AccountNumber=”AW00000510”> <SalesOrderHeader SalesOrderID=”43663” OrderDate=”2001-07-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”44281” OrderDate=”2001-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”45040” OrderDate=”2002-01-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”46606” OrderDate=”2002-07-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”47661” OrderDate=”2002-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”49824” OrderDate=”2003-04-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”55285” OrderDate=”2003-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”61178” OrderDate=”2004-01-01T00:00:00”/> </Customer> </root> 482 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 482 If we have more than one customer, that’s not a problem — we just add another customer node: <?xml version=”1.0” encoding=”UTF-8”?> <root> <Customer CustomerID=”510” AccountNumber=”AW00000510”> <SalesOrderHeader SalesOrderID=”43663” OrderDate=”2001-07-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”44281” OrderDate=”2001-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”45040” OrderDate=”2002-01-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”46606” OrderDate=”2002-07-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”47661” OrderDate=”2002-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”49824” OrderDate=”2003-04-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”55285” OrderDate=”2003-10-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”61178” OrderDate=”2004-01-01T00:00:00”/> </Customer> <Customer CustomerID=”512” AccountNumber=”AW00000512”> <SalesOrderHeader SalesOrderID=”46996” OrderDate=”2002-08-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”48018” OrderDate=”2002-11-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”49090” OrderDate=”2003-02-01T00:00:00”/> <SalesOrderHeader SalesOrderID=”50231” OrderDate=”2003-05-01T00:00:00”/> </Customer> </root> Indeed, this can go to unlimited levels of hierarchy (subject, of course, to whatever your parser can han- dle). We could, for example, add a level for individual line items in the order. Determining Elements vs. Attributes The first thing to understand here is that there is no hard and fast rule for determining what should be an element vs. an attribute. An attribute describes the properties of the element that it is an attribute of. Child elements — or child “nodes” — of an element do much the same thing. So how, then, do we decide which should be which? Why are attributes even necessary? Well, like most things in life, it’s something of a balancing act. Attributes make a lot of sense in situations where the value is a one-to-one relationship with, and is inherently part of, the element. In AdventureWorks2008, for example, we have only one customer num- ber per customer ID — this is ideal for an attribute. As we are transforming our relational data to XML, the columns of a table will often make good attributes to an element directly related to individual rows of a table. Elements tend to make more sense if there is more of a one-to-many relationship between the element and what’s describing it. In our example earlier in the chapter, there are many sales orders for each cus- tomer. Technically speaking, we could have had each order be an attribute of a customer element, but then we would have needed to repeat much of the customer element information over and over again. Similarly, if our AdventureWorks2008 database allowed for the notion of customers having aliases (multiple account numbers — similar to how they have multiple contacts), then we may have wanted to have an AccountNumber element under the customer and have its attribute describe individual instances of names. Whichever way you go here, stick to one rule I’ve emphasized many times throughout the book — be consistent. Once something of a given nature is defined as being an attribute in one place, lean toward keeping it an attribute in other places unless its nature is somehow different in the new place you’re using it. One more time: Be consistent. 483 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/08 7:33 AM Page 483 [...]... 45049 45790 46619 47672 487 32 4 986 6 61 187 43672 44294 45052 45792 46622 47673 487 68 4 986 0 51100 55 287 61222 67272 OrderDate -20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 20 08- 08- 16 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 501 Chapter... Sales.Customer.CustomerID = 2 989 0 OR Sales.Customer.CustomerID = 30067; So, you go hand your boss the results: CustomerID AccountNumber - 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 2 989 0 AW0002 989 0 30067 AW00030067 30067 AW00030067 30067 AW00030067 30067 AW00030067 30067 AW00030067 30067 AW00030067 30067 AW00030067 30067 AW00030067... against yet another schema What SQL Ser ver Brings to the P ar ty So, now we have all the basics of what XML is down What we need is to understand the relevance in SQL Server 486 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 487 Chapter 16: A Brief XML Primer XML functionality was a relatively late addition to SQL Server Indeed, it first appeared as a downloadable add-on to SQL Server 7.0 What’s more, a significant... data types added in SQL Server 2005 and 20 08 ❑ ELEMENTS: This option is available only when you are using the AUTO formatting option It tells SQL Server that you want the columns in your data returned as nested elements rather than as attributes ❑ BINARY BASE64: This tells SQL Server to encode any binary columns (binary, varbinary, image) in base64 format This option is implied (SQL Server will use it... functionality was originally more an addition to Internet Information Server (IIS) than to SQL Server With SQL Server 2000, the XML side of things moved to what Microsoft called a “Web Release” model, and was updated several times With SQL Server 2005, XML finished moving into the core product While most of the old functionality remains supported, SQL Server continues to add more core features that makes XML an... XML_SCHEMA_NAMESPACE() function The syntax looks like this: XML_SCHEMA_NAMESPACE( , , [] ) 488 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 489 Chapter 16: A Brief XML Primer This is just a little confusing, so let’s touch on these parameters just a bit: Parameter Description SQL Server schema This is your relational database schema (not to be confused with... data types), and, last, but not least, a special SQL namespace used for working with SQL Server XML integration Some attributes (including one in the root) are qualified with namespace information (see the sql: relation attribute, for example) 484 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 485 Chapter 16: A Brief XML Primer 489 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 490 Chapter 16: A Brief XML Primer SQL Server strips out any whitespace between tags, so if you create a schema collection with all sorts of pretty indentations for readability, SQL Server will remove them for the sake of efficient storage Again, note that the default . Information Server (IIS) than to SQL Server. With SQL Server 2000, the XML side of things moved to what Microsoft called a “Web Release” model, and was updated several times. With SQL Server 2005,. this: XML_SCHEMA_NAMESPACE( < ;SQL Server schema> , <xml schema collection> , [<namespace>] ) 488 Chapter 16: A Brief XML Primer 57012c16.qxd:WroxBeg 11/25/ 08 7:33 AM Page 488 This is just a. to, say, just taking a SQL Server 20 08 backup. A decade from now when you need to restore some old data to review archival information, you may very well not have a SQL Server installa- tion that