Difference between WCF and Web service

Web service is a part of WCF. WCF offers much more flexibility and portability to develop a service when comparing to web service. Still we are having more advantages over Web service, following table provides detailed difference between them.

Features	Web Service	WCF
Hosting	It can be hosted in IIS	It can be hosted in IIS, windows activation service, Self-hosting, Windows service
Programming	[WebService] attribute has to be added to the class	[ServiceContraact] attribute has to be added to the class
Model	[WebMethod] attribute represents the method exposed to client	[OperationContract] attribute represents the method exposed to client
Operation	One-way, Request- Response are the different operations supported in web service	One-Way, Request-Response, Duplex are different type of operations supported in WCF
XML	System.Xml.serialization name space is used for serialization	System.Runtime.Serialization namespace is used for serialization
Encoding	XML 1.0, MTOM(Message Transmission Optimization Mechanism), DIME, Custom	XML 1.0, MTOM, Binary, Custom
Transports	Can be accessed through HTTP, TCP, Custom	Can be accessed through HTTP, TCP, Named pipes, MSMQ,P2P, Custom
Protocols	Security	Security, Reliable messaging, Transactions

.NET 3.5 changes to GC.Collect

During my talk on Garbage Collection in .NET at the Jacksonville Code Camp 2007, Joe Healy mentioned that I should take a look at the changes made to the GC in the .NET Framework 3.5 release. (This is based on the Beta 2 release, but it should be pretty stable at this point.)

After doing some research using the SSCLI 2.0 code base to look at the GC class as it exists in .NET 2.0 and Reflector to look at it in .NET 3.5, I found the single change that was made. (For those of you wondering why I used SSCLI, when you install the .NET Framework 3.5 it also installs Service Pack 1 for .NET 2.0).

In my talk, and in most of the forum discussions I have about GC, I mention that you really shouldn't "help" the GC by calling GC.Collect. A lot of people have the belief that calling GC.Collect manually will reduce the memory usage of your application and, thereby, increase performance. Calling GC.Collect will potentially decrease the memory usage, but it does so by forcing an "out of cycle" collection to occur. The reason I say "potentially" is that in this out of cycle collection there may not be any objects that are able to be reclaimed. You also suffer a performance hit during the collection cycle. Even though garbage collection cycles run very quickly, in order for the GC to do it's job properly it must freeze your applications main thread before starting the collection cycle. When the collection is finished, the thread is unfrozen. The end result of this is that you are context switching between threads and freezing your application a lot more often than you would be without the calls to GC.Collect, which ultimately will start to hurt your performance. There are times when you should call GC.Collect(), but generally it is discouraged except for debugging purposes.

So, what is the change to the GC? The change adds an overload to the GC.Collect() method:

   1: void System.GC.Collect(int generation, System.GCCollectionMode mode)

According to the MSDN documentation for this overload, this "forces a garbage collection from generation zero through a specified generation, at a time specified by aGCCollectionMode value."

What this really means is that you can use the mode parameter to specify when the collection should occur. The valid values for mode are:

• Default:  This is currently equivalent to Forced.
• Forced:  Forces the garbage collection to occur immediately. This is the same behavior as if you called GC.Collect without specifying the mode.
• Optimized: Allows the garbage collector to determine the optimal time to reclaim objects.

Using the Default or Forced modes is really the same as calling GC.Collect(), so you shouldn't use them except in specific cases (as shown in Rico's blog post). However, the Optimized mode tells the GC "I want to do an out of cycle collection, but only if it's needed." Ultimately, the GC considers a lot of different factors in deciding this, including amount of memory considered garbage and the amount of heap fragmentation. If the GC decides a collection isn't needed, it won't run one and the call will have no effect.

One other thing to keep in mind if you use this new overload is that it doesn't guarantee that all inaccessible objects in the specified generation will be reclaimed. 

Even with this new overload, I still recommend against using GC.Collect (or this overload with the Forced or Default modes) except under very specific circumstances. If you feel you absolutely must add your own calls to GC.Collect, make sure to use the overload and a mode of Optimized. Also, if you have existing code that makes use of calls to GC.Collect, you should take the time to review each of those calls to see if they are still necessary and consider changing them to call the overload with a mode of Optimized.

3 ways to define a JavaScript class

Original Post:http://www.phpied.com/3-ways-to-define-a-javascript-class/

Introduction

JavaScript is a very flexible object-oriented language when it comes to syntax. In this article 

you can find three ways of defining and instantiating an object. Even if you have already picked your favorite way of doing it, it helps to know some alternatives in order to read other people's code.

It's important to note that there are no classes in JavaScript. Functions can be used to somewhat simulate classes, but in general JavaScript is a class-less language. Everything is an object. And when it comes to inheritance, objects inherit from objects, not classes from classes as in the "class"-ical languages.

1. Using a function

This is probably one of the most common ways. You define a normal JavaScript function and then create an object by using the new keyword. To define properties and methods for an object created using function(), you use the this keyword, as seen in the following example.

function Apple (type) {
    this.type = type;
    this.color = "red";
    this.getInfo = getAppleInfo;
}

// anti-pattern! keep reading...
function getAppleInfo() {
    return this.color + ' ' + this.type + ' apple';
}

To instantiate an object using the Apple constructor function, set some properties and call methods you can do the following:

var apple = new Apple('macintosh');
apple.color = "reddish";
alert(apple.getInfo());

1.1. Methods defined internally

In the example above you see that the method getInfo() of the Apple "class" was defined in a separate function getAppleInfo(). While this works fine, it has one drawback – you may end up defining a lot of these functions and they are all in the "global namespece". This means you may have naming conflicts if you (or another library you are using) decide to create another function with the same name. The way to prevent pollution of the global namespace, you can define your methods within the constructor function, like this:

function Apple (type) {
    this.type = type;
    this.color = "red";
    this.getInfo = function() {
        return this.color + ' ' + this.type + ' apple';
    };
}

Using this syntax changes nothing in the way you instantiate the object and use its properties and methods.

1.2. Methods added to the prototype

A drawback of 1.1. is that the method getInfo() is recreated every time you create a new object. Sometimes that may be what you want, but it's rare. A more inexpensive way is to add getInfo() to the prototype of the constructor function.

function Apple (type) {
    this.type = type;
    this.color = "red";
}

Apple.prototype.getInfo = function() {
    return this.color + ' ' + this.type + ' apple';
};

Again, you can use the new objects exactly the same way as in 1. and 1.1.

2. Using object literals

Literals are shorter way to define objects and arrays in JavaScript. To create an empty object using you can do:
var o = {};
instead of the "normal" way:
var o = new Object();
For arrays you can do:
var a = [];
instead of:
var a = new Array();
So you can skip the class-like stuff and create an instance (object) immediately. Here's the same functionality as described in the previous examples, but using object literal syntax this time:

var apple = {
    type: "macintosh",
    color: "red",
    getInfo: function () {
        return this.color + ' ' + this.type + ' apple';
    }
}

In this case you don't need to (and cannot) create an instance of the class, it already exists. So you simply start using this instance.

apple.color = "reddish";
alert(apple.getInfo());

Such an object is also sometimes called singleton. It "classical" languages such as Java,singleton means that you can have only one single instance of this class at any time, you cannot create more objects of the same class. In JavaScript (no classes, remember?) this concept makes no sense anymore since all objects are singletons to begin with.

3. Singleton using a function

Again with the singleton, eh? 

The third way presented in this article is a combination of the other two you already saw. You can use a function to define a singleton object. Here's the syntax:

var apple = new function() {
    this.type = "macintosh";
    this.color = "red";
    this.getInfo = function () {
        return this.color + ' ' + this.type + ' apple';
    };
}

So you see that this is very similar to 1.1. discussed above, but the way to use the object is exactly like in 2.

apple.color = "reddish";
alert(apple.getInfo());

new function(){...} does two things at the same time: define a function (an anonymous constructor function) and invoke it with new. It might look a bit confusing if you're not used to it and it's not too common, but hey, it's an option, when you really want a constructor function that you'll use only once and there's no sense of giving it a name.

Summary

You saw three (plus one) ways of creating objects in JavaScript. Remember that (despite the article's title) there's no such thing as a class in JavaScript. Looking forward to start coding using the new knowledge? Happy JavaScript-ing!

Understanding XSD and XML Schema definition

Original Post By Ramesh Balaji : http://www.codeguru.com/csharp/csharp/cs_data/xml/article.php/c19441/Understanding-XSD-Schema.htm

Those who deal with data transfer or document exchange within or across organizations with heterogeneous platforms will certainly accept and appreciate the need and power of XML. I am not going to delve into the merits of XML. I will, however, address a simple but powerful schema concept called XSD or XML Schema Definition.

• What is XSD Schema?
• What are the advantages of XSD Schema?
• What is important in XSD Schema?

What Is a Schema?

A schema is a "Structure", and the actual document or data that is represented through the schema is called "Document Instance". Those who are familiar with relational databases can map a schema to a Table Structure and a Document Instance to a record in a Table. And those who are familiar with object-oriented technology can map a schema to a Class Definition and map a Document Instance to an Object Instance.

A structure of an XML document can be defined as follows:

• Document Type Definition (DTDs)
• XML Schema Definition (XSD)
• XML Data Reduced (XDR) -proprietary to Microsoft Technology

We are specifically going to work with XML Schema Definitions (XSD).

What Is XSD?

XSD provides the syntax and defines a way in which elements and attributes can be represented in a XML document. It also advocates that the given XML document should be of a specific format and specific data type.

XSD is fully recommended by W3C consortium as a standard for defining an XML Document. To know more about latest information on XSD, please refer the W3C site (www.w3.org).

Advantages of XSD

So what is the benefit of this XSD Schema?

• XSD Schema is an XML document so there is no real need to learn any new syntax, unlike DTDs.
• XSD Schema supports Inheritance, where one schema can inherit from another schema. This is a great feature because it provides the opportunity for re-usability.
• XSD schema provides the ability to define own data type from the existing data type.
• XSD schema provides the ability to specify data types for both elements and attributes.

Case Study

ABC Corp. a fictitious software consultancy firm, which employs around 25 people, has been requested by its payroll company to submit employee information, which includes the Full Time and Part Time consultants, electronically in an XML format to expedite payroll processing.

The Payroll Company told ABC Corp. the following information will be needed for the Full Time and Part Time Employees.

Employee Information

SSN Name DateOfBirth EmployeeType Salary

Here is the actual XML document for the above information.

  <?xml version="1.0" ?> 

- <Employees xmlns="http://www.abccorp.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.abccorp.com/employee.xsd">
- <Employee>
  <SSN>737333333</SSN> 
  <Name>ED HARRIS</Name> 
  <DateOfBirth>1960-01-01</DateOfBirth> 
  <EmployeeType>FULLTIME</EmployeeType> 
  <Salary>4000</Salary> 
  </Employee>

  </Employees>

Here is the XML Schema for the above Employee Information

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">
           <xsd:complexType>
              <xsd:sequence>

                 <xsd:element name="SSN="xsd:string>
                 <xsd:element name="Name" type="xsd:string"/>
            <xsd:element name="DateOfBirth" type="xsd:date"/>
           <xsd:element name="EmployeeType" type="xsd:string"/>
           <xsd:element name="Salary" type="xsd:long"/>
             </xsd:sequence>

          </xsd:complexType>
        </xsd:element>
  </xsd:schema>

Let's examine each line to understand the XSD Schema.

Schema Declaration

For an XSD Schema, the root element is <schema>. The XSD namespace declaration is provided with the<schema > to tell the XML parser that it is an XSD Schema.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

The namespace that references an XSD Schema is the W3C recommended version of XSD. The "xsd:" prefix is used to make sure we are dealing with XSD Schema, but any prefix can be given.

Element Declaration

"Element" is the important part of the schema because it specifies the kind of information. The following element declaration in our example is going to deal with Employee information.

        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">

An "element" declaration in XSD should have the following attributes.

name: This attribute specifies the name of an element. "Employee" in our example.

type: This attribute refers to Simple Type or Complex Type, which will be explained very soon in this article.

minoccurs: This attribute will specify how many elements at a Minimum will be allowed. The default is '0", which means it is an optional element.

Assume that minoccurs attribute carries a value of "1". This would mean the "Employee" element should be specified at least once in the XML document.

maxoccurs: This attribute will specify how many elements at a Maximum will be allowed in an XML document. Assume that maxoccurs attribute carries a value of "2". This would mean the "Employee" element should NOT be specified more than twice.

To summarize, let's say the minoccurs is "1" and maxoccurs is "2" for the "Employee" element. This means there should be atleast one instance of the "Employee" element in the XML document, but the total number of instances of "Employee" element shouldn't exceed two.

If you tried passing three instances of "Employee" element in the XML document, the XML parser will throw an error.

To allow the "Employee" element to be specified an unlimited number of times in an XML document, specify the "unbounded" value in the maxoccurs attribute.

The following example states that the "Employee" element can occur an unlimited number of times in an XML document.

        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">

Complex Type

An XSD Schema element can be of the following types:

• Simple Type
• Complex Type

In an XSD Schema, if an element contains one or more child elements or if an element contains attributes, then the element type should be "Complex Type"

<xsd:complexType>
        <xsd:sequence>
          <xsd:element name="SSN="xsd:string>

           <xsd:element name="Name" type="xsd:string"/>
       <xsd:element name="DateOfBirth" type="xsd:date"/>
      <xsd:element name="EmployeeType" type="xsd:string"/>
      <xsd:element name="Salary" type="xsd:int"/>
          </xsd:sequence>
  </xsd:complexType>

The Employee element has SSN, Name, Date of Birth, Salary and Employee type, which are specified as child elements. As a result Employee Element must be defined as a Complex Type because there are one or more elements under Employee element.

xsd:sequence

The <xsd:sequence> specifies the order in which the elements need to appear in the XML document. This means the elements SSN, Name, DateOfBirth, EmployeeType and Salary should appear in the same order in the XML document. If the order is changed, then the XML parser will throw an error.

Simple Type

In an XSD Schema an element should be referred to as a Simple Type when you create a User Defined type from the given base data type.

Before going further into Simple Types, I would like to mention that XSD provides a wide variety of base data types that can be used in a schema. A complete description of the data types is beyond the scope of this article.

I would suggest reading at the following Web sites to learn more about data types.

• http://www.w3.org
• http://msdn.microsoft.com search for XSDs.

Some of the base data types, which we used in the "Employee" element examples, are:

• xsd:string
• xsd:int
• xsd:date

Knowing that Simple Type Elements can specify User-defined data types in XML Schema, the real question is how do we know where to use a specific Simple Type?

Let's take a look at the schema again.

<xsd:complexType>
     <xsd:sequence>
         <xsd:element name="SSN="xsd:string>
         <xsd:element name="Name" type="xsd:string"/>
      <xsd:element name="DateOfBirth" type="xsd:date"/>

     <xsd:element name="EmployeeType" type="xsd:string"/>
     <xsd:element name="Salary" type="xsd:int"/>
     </xsd:sequence>
  </xsd:complexType>

Assume the Payroll processing company wants the social security number of the employees formatted as "123-11-1233".

For this we will create a new data type called "ssnumber".

The following is the code to accomplish the above requirement.

<xsd:simpleType name="ssnumber">
    <xsd:restriction base="xsd:string">
     <xsd:length value="11">
     <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>
    </xsd:restriction>

 </xsd:simpleType>

To start with, we should provide the name of the Simple Type, which is "ssnumber".

The restriction base specifies what is the base data type in which we derive the User Defined Data type, which is the "string" data type in the above example.

To restrict the social security number to 11 characters, we require the length value to be "11".

To ensure the social security number appears in the "123-11-1233" format, the pattern is specified in the following format.

      <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>

To explain the pattern,

\d{3} specifies that there should be three characters in the start. Followed by two characters after the first "-" and finally followed by four characters after the second "-".

Incorporating Simple Types into Schema

Now that we know what Simple Type means, let us learn how to effectively incorporate Simple Type into an XSD Schema.

First of all, Simple Types can be global or local.

Let's first look at global usage of Simple Type Element "ssnumber".

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">
      <xsd:complexType>
              <xsd:sequence>

                 <xsd:element name="SSN= type ="xsd:ssnumber>
                 <xsd:element name="Name" type="xsd:string"/>
       <xsd:element name="DateOfBirth" type="xsd:date"/>
      <xsd:element name="EmployeeType" type="xsd:string"/>
      <xsd:element name="Salary" type="xsd:int"/>
             </xsd:sequence>

    </xsd:complexType>
     </xsd:element>


    <xsd:simpleType name="ssnumber">
     <xsd:restriction base="xsd:string">
   <xsd:length value="11">

       <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>
     </xsd:restriction>
  </xsd:simpleType>


  </xsd:schema>

In the above example, the child element name "SSN" of parent element "Employee" is defined as user defined data type "ssnumber".

The Simple Type element "ssnumber" is declared outside the Employee element, which means if we have to define another element, say for ex. "Employer" inside the <xsd:schema>, then the "Employer" element can still make use of the "ssnumber" data type if it's needed.

Let's examine a different case where the Simple Type element "ssnumber" will be specific to Employee, and it is not going to be needed elsewhere at all. Then the following schema structure accomplishes this.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">
           <xsd:complexType>
              <xsd:sequence>

                 <xsd:element name="SSN="xsd:string>


  <xsd:simpleType>
      <xsd:restriction base="xsd:string">
    <xsd:length value="11">
        <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>

      </xsd:restriction>
   </xsd:simpleType>


           <xsd:element name="Name" type="xsd:string"/>
       <xsd:element name="DateOfBirth" type="xsd:date"/>
      <xsd:element name="EmployeeType" type="xsd:string"/>

      <xsd:element name="Salary" type="xsd:int"/>
 </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
  </xsd:schema>

In the above example, all restrictions such as max length, pattern and base data type are declared inline, and it immediately follows the SSN element.

Understanding Schema Flexibility

So far we have seen how to create a schema by:

a. Declaring and Using Complex Element Type
b. Declaring and Using Simple Element Type
c. Understanding Global scope and Local scope of a given element

I will now explain the flexibility XSD Schema can provide by extending our schema example.

Let's validate further by adding a "FullTime" or "PartTime" Employee Type element.

To provide the validation, we should create a Simple Element Type called "emptype".

  <xsd:simpleType name="emptype">

    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="fulltime"/>
      <xsd:enumeration value="parttime"/>
    </xsd:restriction>
  </xsd:simpleType>  

The above schema will successfully create a Simple Type element with base type as "string" data type. The enumeration values are specified in enumeration attributes, which will basically restrict within two values. The enumeration attributes in an XSD Schema provides the ability to define an element in such a way that it should fall between the values given in the enumeration list.

Let us incorporate emptype Simple Type element in our main Employee schema.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">
           <xsd:complexType>

              <xsd:sequence>
                 <xsd:element name="SSN="xsd:ssnumber>
                 <xsd:element name="Name" type="xsd:string"/>
       <xsd:element name="DateOfBirth" type="xsd:date"/>


      <xsd:element name="EmployeeType" type="xsd:emptype"/>



      <xsd:element name="Salary" type="xsd:int"/>
             </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
 <xsd:simpleType name="ssnumber">

     <xsd:restriction base="xsd:string">
   <xsd:length value="11">
       <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>
     </xsd:restriction>
  </xsd:simpleType>



 <xsd:simpleType name="emptype">
     <xsd:restriction base="xsd:string">
       <xsd:enumeration value="fulltime"/>
       <xsd:enumeration value="parttime"/>
     </xsd:restriction>
   </xsd:simpleType>


 
  </xsd:schema>

In the above example, the child element name "EmployeeType" of parent element "Employee" is defined as user defined data type "emptype".

The Simple Type element "emptype" is declared outside the Employee element which is global to elements that fall under <xsd:schema>

So we have defined two simple element types: one is emptype, which basically restricts the value within twoenumerated values "fulltime" or "parttime". And another is "ssnumber" which restricts the length of the value to 11 and it should be of "111-11-1111" pattern.

I highlighted the words "enumerated" "length" and "pattern" to emphasize that those words are referred to asFacets.

In XSD Schema, facets provide the flexibility to add restriction for a given base data type. In our examples above, the base data type specified is "string".

Similarly, facets are available for other data types like "int". A few facets available for "int" data type are Enumerated, Minexclusive, Mininclusive, and Pattern.

Let's consider a new requirement. The payroll company wants to process tax information, so they want the employee information which is listed above plus the employee's state and zip code information. All the information should be under the separate header "EmployeeTax".

The above requirement compels us to restructure the schema.

First we will break down the requirement to make it simple.

a. Payroll Company wants all the information listed under "Employee" element.
b. Payroll Company wants state and zip of the given Employee.
c. Payroll company wants (a) and (b) in a separate header "EmployeeTax"

Fortunately XSD Schema supports object-oriented principles like Inheritance hierarchy. This principle comes handy in our requirement.

The following structure can quite easily accomplish the above requirement.

<xsd:complexType name="EmployeeTax"
      minOccurs="0" 
            maxOccurs="unbounded">


    <xsd:complexContent>
      <xsd:extension base="xsd:Employee">



        <xsd:sequence>
          <xsd:element name="state" type="xsd:string"/>
          <xsd:element name="zipcode" type="xsd:string"/>
        </xsd:sequence>


      </xsd:extension>

    </xsd:complexContent>


  </xsd:complexType>
  </xsd:schema>

In the above code, we started with the name of the Complex Type, which is "EmployeeTax".

The following line is very important. It tells the XML Parser that some portion of EmployeeTax content is getting derived from another Complex Type.

    <xsd:complexContent>

To refresh our memory, in simple element type definitions, we used restriction base, which mapped to base data types. In the same way, we need to specify the restriction base for the complex content. The restriction base for complex content should logically be another Complex Type. In our example it is "Employee".

  <xsd:extension base="xsd:Employee">

Once the extension base has been defined, all the elements of the "Employee" element will automatically inherit to EmployeeTax Element.

As part of the business requirement, the state and zip code elements are specified which completes the total structure for EmployeeTax Element.

Referencing External Schema

This feature is very useful in situations where one schema has functionality that another schema wants to utilize.

Take a case where the payroll company for ABC Corp. needs some information about the Employers, such as EmployerID and PrimaryContact in a separate XML document.

Assume EmployerID format is the same as Employee SSN format. Since we have already defined the validation for Employee SSN, there exists a valid case for using the Employee schema.

The first step in using different schema is to "include" the schema.

To include the schema, make sure the target namespace is the same as your current working location.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://www.abccorp.com">
<xsd:include schemaLocation="employee.xsd"/>


        <xsd:element name="Employer"
                     minOccurs="0" 
                     maxOccurs="unbounded">
           <xsd:complexType>

              <xsd:sequence>


                      <xsd:element ref ="ssnumber"/>


                 <xsd:element name="PrimaryContact" 
type="xsd:string"/>


  </xsd:sequence>

          </xsd:complexType>
        </xsd:element>
  </xsd:schema>

Please note the include statement, which references the schema location. Make sure the employee.xsd file exists in the same target namespace location.

Once included, the "Employer" element references the ssnumber global element in the same manner as it had been declared within the document itself. Then an additional primary contact element, which is specific to "Employer" element, is defined after the ssnumber element reference.

Annotations

Comments have always been considered a good coding convention. XSD Schema provides a commenting feature through the <Annotation> element.

The <Annotation> element has 2 child elements.

• <documentation>
• <appInfo>

<documentation> element provides help on the source code in terms of its purpose and functionality.

<appinfo> element provides help to the end users about the application.

The following schema describes the usage of the Annotation element.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

        <xsd:element name="Employee"
                     minOccurs="0" 
                     maxOccurs="unbounded">
           <xsd:complexType>
              <xsd:sequence>
                 <xsd:element name="SSN="xsd:ssnumber>


     <xsd:annotation>

          <xsd:documentation>
   The SSN number identifies each employee of ABC CORP
                    </xsd:documentation>
           <xsd:appInfo>
   Employee Payroll Info
                    </xsd:appInfo>
            </xsd:annotation>



           <xsd:element name="Name" type="xsd:string"/>
       <xsd:element name="DateOfBirth" type="xsd:date"/>
      <xsd:element name="EmployeeType" type="xsd:emptype"/>
      <xsd:element name="Salary" type="xsd:int"/>
             </xsd:sequence>

          </xsd:complexType>
        </xsd:element>
 <xsd:simpleType name="ssnumber">
     <xsd:restriction base="xsd:string">
   <xsd:length value="11">
       <xsd:pattern value="\d{3}\-\d{2}\-\d{4}"/>

     </xsd:restriction>
  </xsd:simpleType>
 <xsd:simpleType name="emptype">
     <xsd:restriction base="xsd:string">
       <xsd:enumeration value="fulltime"/>
       <xsd:enumeration value="parttime"/>

     </xsd:restriction>
   </xsd:simpleType>  
  </xsd:schema>

Conclusion

I tried to cover a few interesting features of XSD Schema. But there is a whole lot of information about XSD schema in

www.w3c.org

http://msdn.microsoft.com - search for XSDs.

Happy Reading.

About the Author

Ramesh Balaji develops business applications using ASP, VB and SQL Server. He's a frequent contributor to www.4guysfromrolla.com. When not programming, he enjoys spending time with his kids. He can be reached at iambramesh@yahoo.com.