Ok, I know I have a few groups of posts started, so you won't mind me starting another one, right?
Right, so this collection of posts will be all about XML. If you're not using it already, or completely familiar with what you can do with XML, check out this collection. I'm hoping to cover the basics through a few more complex topics like Document Type Definitions (DTD) and Schemas.
Let's begin!
Extensible Markup Language, or XML, is the language for handling data in a compact, easy-to-manage form. XML is all about storing and transferring data—phone directories, business orders, book lists, anything you like.
HTML, on the other hand is about displaying your data. This is part of the purpose for XML. It's designed to mark up the data being presented separate from the look and feel, or part of the interactivity of the data. XML can drive those things, but the XML file is never concerned with those things.
It's agnostic.
XML is a markup language. Markup refers to codes or tokens that explain how to interpret the different elements in the document. You should be familiar with HTML, it's a markup language that tells a web browser how to render the data in the HTML file. Similarly XML is a markup document that can explain how the data is related, and how to make sense of the data in that document.
The big idea behind XML is you can build your own markup. You can design your files in such a way that each file perfectly handles the data you're asking that file to store and transport. Technically, XML is a meta-language, which means it's a language that lets you create your own markup languages.
XML provides you with a way of structuring your data in documents. The reason it's taken off so quickly is it's perfect for the Internet—because XML documents are text, you can send them using the existing Internet technology that was built for HTML.
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
Hello From XML
</heading>
<message>
This is an XML document!
</message>
</document>
This is a sample XML file. This document starts with an XML declaration,<?xml version="1.0" encoding="UTF-8"?>. This XML declaration indicates that we're using XML version 1.0, and using the UTF-8 character encoding, which means that we're using an 8-bit condensed version of Unicode. For now, let's just say, you're going to want to include this at the top of each of the XML files you make. Without it, your file may not be understood by most XML parsers. In the future, I will show you how to alter this declaration to provide altered functionality for your XML file.
The elements after the xml declaration can be anything you define. Just make sure any interpreter that reads this understands the file you're storing/transmitting, otherwise you'll have a mess on your hands. In this case, I just defined two elements, heading, and document. Notice I've closed both of them. Well formed documents will close all elements opened. It makes life easier when you start dealing with interpreters.
If you save this code in a file with a name including ".xml" you can open this file in any web browser and check it out. Next time, we'll go into how you can work with xml files in browsers and go into a little more detail on what is and isn't well formed xml.
Any questions? Send them in, I'm here to help!
We all know that in previous versions of SQL Server 2008 we have just one data type for storing date and time data, DATETIME. The problem is sometimes we only needed date, or we only needed time. Now you have some new options!
TIME
DECLARE@myTime TIME
SET @myTime = GETDATE()
SELECT@myTime as myTime
By default, SQL Server 2008 will store 7 decimal places of precision. if you need less, you can indicate that! Let's say I only want 3 decimal places (to more closely emulate the precision from older versions of SQL Server).
DECLARE@myTime TIME(3)
SET@myTime = GETDATE()
SELECT @myTime as myTime
Pretty nice, right?
DATE
If you need to store just a DATE, you have that ability now! A DATE value can be anything from 0001-01-01 through 9999-12-31.
DECLARE @myDate DATE
SET @myDate = GETDATE()
SELECT @MyDate as myDate
DATETIME2
Now that we have the new DATE data type, and the new TIME data type, if you want to combine them, you could use DATETIME, but if you wanted the extra precision of the TIME data type, then you'll want to use DATETIME2.
DECLARE @myDate DATETIME2
SET @myDate = GETDATE()
SELECT @MyDate as myDate
As for now, DATETIME is still sticking around. I haven't seen anything that says it's deprecated, or non-standard to use it, but now that you have DATETIME2, maybe you can use the extra precision provided.
If you have any questions, send them in, I'm here to help!
