Everything in a Language Stems from a Historic Need

I remember wondering what the big deal was with the Exception type. I guess it was annoying not being able to return an error from, say, constructors:

"The use of exceptions adds to a consistent framework design and allows error reporting from members, such as constructors, that cannot have a return type." - http://msdn.microsoft.com/en-us/library/ms229014

XML to an HTML table in C#

Nodes aren't just elements...

Caught myself thinking that. So to set my mind right:

According to the DOM, everything in an XML document is a node.

The DOM says:

• The entire document is a document node
• Every XML element is an element node
• The text in the XML elements are text nodes
• Every attribute is an attribute node
• Comments are comment nodes

Text is Always Stored in Text Nodes

A common error in DOM processing is to expect an element node to contain text.

However, the text of an element node is stored in a text node.

In this example: <year>2005</year>, the element node <year>, holds a text node with the value "2005".

"2005" is not the value of the <year> element!

This is exacerbated by JavaScript referring to nodeValue ....

XML Elements vs. Attributes

XML Elements vs. Attributes

Take a look at these examples:

<person sex="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

<person>
  <sex>female</sex>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

In the first example sex is an attribute. In the last, sex is an element. Both examples provide the same information.

There are no rules about when to use attributes or when to use elements.

However, YOU SHOULD AVOID USING ATTRIBUTES WHEN POSSIBLE.  USE ELEMENTS INSTEAD. (except for true MetaData)

The following three XML documents contain exactly the same information:
A date attribute is used in the first example:

<note date="10/01/2008">
  <to>Tove</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

A date element is used in the second example:

<note>
  <date>10/01/2008</date>
  <to>Tove</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

An expanded date element is used in the third:

<note>
  <date>
    <day>10</day>
    <month>01</month>
    <year>2008</year>
  </date>
  <to>Tove</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

---

Avoid XML Attributes?

Some of the problems with using attributes are:

• attributes cannot contain multiple values (elements can)
• attributes cannot contain tree structures (elements can)
• attributes are not easily expandable (for future changes)

Attributes are difficult to read and maintain. Use elements for data. Use attributes for information that is not relevant to the data.
Don't end up like this:

<note day="10" month="01" year="2008"
to="Tove" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>

---

XML Attributes for Metadata

Sometimes ID references are assigned to elements. These IDs can be used to identify XML elements in much the same way as the id attribute in HTML. This example demonstrates this:

<messages>
  <note id="501">
    <to>Tove</to>
    <from>Jani</from>
    <heading>Reminder</heading>
    <body>Don't forget me this weekend!</body>
  </note>
  <note id="502">
    <to>Jani</to>
    <from>Tove</from>
    <heading>Re: Reminder</heading>
    <body>I will not</body>
  </note>
</messages>

The id attributes above are for identifying the different notes. It is not a part of the note itself.
So, metadata (data about data) should be stored as attributes, and the data itself should be stored as elements.

excerpted from http://www.w3schools.com/xml/xml_attributes.asp

new line

In Windows applications, a new line is normally stored as a pair of characters: carriage return (CR) and line feed (LF). In Unix applications, a new line is normally stored as an LF character. Macintosh applications also use an LF to store a new line.

XML stores a new line as LF.

Industry Maneuvers

This is kind of big news for a whole cornocopia of developers because of what it says about the effect Apple ultimately has on Microsoft as well as Flash:

https://www.zdnet.com/blog/microsoft/xamarin-abandons-its-silverlight-for-linux-technology/12797

The worm turns: Embedded SQL vs Stored Procs

Written by James Kovacs about 5 years ago.

Historically Microsoft recommended stored procs because they gave much better performance. Query optimizers in SQL Server 2000 and 2005 have improved dramatically and this is no longer much of an issue. The biggest hassle with stored procs is you have two places to maintain and version code — namely your application and the database. Versioning is much more painful because even without database schema changes, you need the correct set of stored procs for the code base that is running against them. When you’re pulling apart the result set, you need to compare the columns in the stored proc select statements against the columns that your DataReaders are expecting. A trivial task, but mind-numbingly boring. It’s easier if the select is in close proximity to the code that parses it. Personally I’m a big fan of having an ORM tool such as NHibernate or LINQ generate the dynamic queries for me and perform the parsing. I honestly think that’s the way of the future and hand-optimized stored procs will be used for perf critical operations when needed.

And Microsoft doesn't provide a good way of organizing and managing Stored Procedures into folders.