You are on page 1of 9

W3C Introduction

What it W3C?
W3C Stands for the World Wide Web Consortium W3C was created in October 1994 W3C was created by Tim Berners-Lee W3C was created by the Inventor of the Web W3C is organized as a Member Organization W3C is working to Standardize the Web W3C creates and maintains WWW Standards W3C Standards are called W3C Recommendations

How it Started
The World Wide Web (WWW) began as a project at the European Organization for Nuclear Research (CERN), where Tim Berners-Lee developed a vision of the World Wide Web. Tim Berners-Lee - the inventor of the World Wide Web - is now the Director of the World Wide Web Consortium (W3C). W3C was created in 1994 as a collaboration between the Massachusetts Institute of Technology (MIT) and the European Organization for Nuclear Research (CERN), with support from the U.S. Defense Advanced Research Project Agency (DARPA) and the European Commission.

Standardizing the Web


W3C is working to make the Web accessible to all users (despite differences in culture, education, ability, resources, and physical limitations) W3C also coordinates its work with many other standards organizations such as the Internet Engineering Task Force, the Wireless Application Protocols (WAP) Forum and the Unicode Consortium.

W3C is hosted by three universities:


Massachusetts Institute of Technology in the U.S. The French National Research Institute in Europe Keio University in Japan

W3C Members
Because the Web is so important (both in scope and in investment) that no single organization should have control over its future, W3C functions as a member organization.

Some well known members are:

IBM Microsoft America Online Apple Adobe Macromedia Sun Microsystems

W3C Recommendations
The most important work done by the W3C is the development of Web specifications (called "Recommendations") that describe communication protocols (like HTML and XML) and other building blocks of the Web. Each W3C Recommendation is developed by a work group consisting of members and invited experts. The group obtains its input from companies and other organizations, and creates a Working Draft and finally a Proposed Recommendation. In general the Recommendation is submitted to the W3C membership and director, for a formal approval as a W3C Recommendation. The specification approval process is described in the next chapter.

The W3C standards approval process includes up to 7 different steps.

W3C Specification Approval Steps


When W3C is publishing a new Web standard, the specification has worked its way from an idea through a lot of refining processes including the following: W3C receives a Submission W3C publishes a Note W3C creates a Working Group W3C publishes a Working Draft W3C publishes a Candidate Recommendation W3C publishes a Proposed Recommendation W3C publishes a Recommendation

W3C Submissions Any W3C member can submit a suggestion for a Web standard to the consortium. Most W3C Recommendations started as a submission to the consortium. If a submission is within the W3C work area (or charter), the W3C will decide if they should start working to refine the suggestion.

W3C Notes Often a submission to the W3C becomes a Note. A Note is a description of a suggestion refined as a public document. A Note is made available by the W3C for discussion only. Publication of a Note indicates no endorsement by W3C. The content of a Note is edited by the member that submitted the Note, and not by the W3C. A Note may be updated, replaced, or rendered obsolete at any time. The publication of a Note does not indicate that the W3C has started any work related to the Note.

W3C Working Groups When a submission is acknowledged by the W3C, a Working Group consisting of members and other interested parties is formed. The Working Group will normally define a time schedule and issue a Working Draft of the proposed standard, describing the work in progress.

W3C Working Drafts W3C Working Drafts are normally posted on the W3C Web site, along with an invitation for public comments. A Working Draft indicates work in progress, but should not be used as reference material. The content may be updated, replaced, or rendered obsolete at any time.

W3C Candidate Recommendations Some specifications are more complex than others, and might require more input, more time, and more testing from members and software vendors. Sometimes these specifications are published as Candidate Recommendations. A Candidate Recommendation is also a "work in progress" and should not be used as reference material. The document may be updated, obsolete, and replaced at any time.

W3C Proposed Recommendations A Proposed Recommendation represents the final stage of the work in the Working Group.

A Proposed Recommendation is still a "work in progress" and may still be updated, obsolete, and replaced. But even if it does not imply any official endorsement by the W3C, most often a Proposed Recommendation is close to the final Recommendation both in content and in time.

W3C Recommendations W3C Recommendations have been reviewed by the W3C members, and have the W3C's director's stamp of approval. A W3C Recommendation is considered a stable document and may be used as reference material.

W3C HTML Specifications and Timeline


Specification HTML 3.2 HTML 4.0 HTML 4.01 HTML 5 Recommendation 14. January 1997 24. April 1998 24. December 1999 19. October 2010 (latest draft)

W3C HTML Specifications and Timeline


Specification XHTML 1.0 XHTML 1.0 Revision XHTML 1.1 XHTML Modules XHTML Modules 1.1 XHTML Basic XHTML Basic 1.1 XHTML Events XHTML Print XHTML Media Types (SE) 16. Jan 2009 Draft / Proposal Recommendation 26. Jan 2000 01. Aug 2002 31. May 2001 10. Apr 2001 08. Oct 2008 19. Dec 2000 29. Jul 2008 14. Oct 2003 20. Sep 2006

XHTML 2.0

26. Jul 2006

XForms 1.0 XForms 1.0 (Third Edition) XForms 1.1 18. Aug 2009

14. Oct 2003 29. Oct 2007

XLink HLink 13. Sep 2002

27. Jun 2001

W3C XML Specifications and Timeline


Specification XML 1.0 XML 1.0 (2.Ed) XML 1.0 (3.Ed) XML 1.0 (5.Ed) Draft / Proposal Recommendation 10. Feb 1998 06. Oct 2000 04. Feb 2004 26. Nov 2008

XML 1.1 XML 1.1 (2.Ed)

04. Feb 2004 16. Aug 2006

XML 1.0 Namespaces XML 1.0 Namespaces (2.Ed) XML 1.1 Namespaces XML 1.1 Namespaces (2.Ed)

14. Jan 1999 16. Aug 2006 04. Feb 2004 16. Aug 2006

XML Infoset XML Infoset (2.Ed)

24. Oct. 2001 04. Feb. 2004

XML Base XML Base (2.Ed) XLink 1.0 XPointer Framework XPointer element() scheme XPointer xmlns() scheme XInclude 1.0 XInclude 1.0 (2.Ed)

27. Jun 2001 28. Jan 2009 27. Jun 2001 25. Mar 2003 25. Mar 2003 25. Mar 2003 20. Dec 2004 15. Nov 2006

XML Processing Model

05. Apr 2004

XMLHttpRequest Object

19. Nov 2009

JSP Versus Java Servlets


Before the advent of JSP, the most-used Java technology that could generate dynamic Web page content was Java servlets. Because JSPs eventually are compiled into Java servlets, you can do as much with JSPs as you can do with Java servlets. However, coding JSPs is easier than coding Java servlets. With JSPs, you place static text by coding HTML tags as opposed to Java servlets, in which you place static text by coding a plentitude of println statements. With JSPs, you change static text by changing HTML; and with Java servlets, you change static text by modifying a Java servlet (don t forget the compile/debug cycle!).

JSP Versus Active Server Pages


Active Server Pages (ASP) is the Microsoft solution for providing dynamic Web content. Actually, ASP looks very similar to JSP; both use custom tags to implement business logic and text (HTML) for invariant Web page parts.

However, the devil is in the details, as described in the following: l ASP uses VBScript or JScript, a Microsoft flavor of JavaScript, as its scripting language, whereas JSP uses Java, a more powerful language than VBScript or JScript. The ASP developer typically uses a Microsoft Web server platform or requires a third party product that permits ASP execution on non-Microsoft platforms. The JSP developer has a wide variety of Web server platforms available for use. Note These third parties must port Microsoft software components, such as ActiveX, to different platforms in order for ASP to be used on these platforms. l An ASP is interpreted every time the page is invoked, whereas a JSP is interpreted only the first time the page is invoked (or when the page is changed). However, Microsoft has overcome the previously mentioned limitations of ASP with its release of ASP.NET. ASP.NET, formerly ASP+, promises to be a serious contender against JSP. As of this writing, you may download the ASP.NET Beta-2 release from http://www.asp.net/.

JSPs Versus Client-Side Scripting


Client-side scripting with JavaScript or VBScript is certainly handy and useful, but it does present several problems, including the following: You must count on the customer's browser to have scripting enabled, which, of course, you can Different customers may use different browsers. And coding client-side scripts that work on different browsers can be a headache. Scripting languages used on the client side cannot match the strength and versatility of Java. Client-side scripting languages have very limited access to server-side resources, such as databases. JavaServer pages have access to all server-side resources within the welldefined architecture of J2EE. You have the usual problems of maintaining software on the client that caused your organization to thin the client in the first place. JSP enables a clean separation of business logic from presentation. JSP, by using Java as the scripting language, is not limited to a specific vendor platform. JSP, as an integral part of the J2EE architecture, has full access to server-side resources.

In short, the advantages of using JSP over competing technologies are as follows:

VI. Conclusions
The J2EE verses .NET battle will be the soap opera of the decade for geeks to watch. But there are promises and realities about both platforms. For example, J2EE is a rather brilliant move on the vendors' part, but should not be seen as an altruistic initiative. All vendors that participate in

J2EE are after financial gains, as well as an effective weapon against Microsoft. J2EE enables these vendors to collaborate together and stand ground. Many of these vendors have undergone recent mergers and acquisitions themselves, and so organizations must exercise good judgment when choosing such a platform. As far as Microsoft.NET, that is far from an altruistic initiative. It is a monopolistic initiative dressed in altruism. Microsoft has been claiming that .NET is about open and interoperable web services, when in reality Microsoft is already making their web services closed and proprietary. Microsoft will likely increase the costs of their solutions if a monopoly can be achieved, and innovation will be slowed down significantly. So what's a company like yours to do? Both platforms are useful, and both can lead you to the same destination. Which platform is right for you? When deciding, we recommend you concentrate on the larger business issues. Think about your existing developer skillsets, your existing systems, your existing vendor relationships, and your customers. Those almost always drive the decision, not the minor features. Arguments supporting both platforms Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET) You can build web services today using both platforms Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET. Both platforms offer a single-vendor solution. The scalability of both solutions are theoretically unlimited. .NET has Microsoft's A-team marketing it .NET released their web services story before J2EE did, and thus has some mind-share .NET has a better story for shared context today than J2EE .NET has an awesome tool story with Visual Studio.NET .NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot .NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications .NET benefits from being strongly interweaved with the underlying operating system J2EE is being marketed by an entire industry J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and introduces risk as with any first-generation technology Only J2EE lets you deploy web services today Existing J2EE code will translate into a J2EE web services system without major rewrites. Not true for Windows DNA code ported to .NET.

Arguments for .NET and against J2EE

Arguments for J2EE and against .NET

.NET web services are not interoperable with current industry standards. Their BizTalk framework has proprietary SOAP extensions and does not support ebXML. J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features J2EE lets you take advantage of existing hardware you may have J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous deployment environments. J2EE has a better legacy integration story through the Java Connector Architecture (JCA) J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in. J2EE lets you use Java, which is better than C# due to market-share and maturity. According to Gartner, there are 2.5 million Java developers. IDC predicts this will grow to 4 million by 2003. 78% universities teach Java, and 50% of universities require Java. We would not want to use any language other than C# or Java for development of new mission-critical solutions, such as a hacked object-oriented version of C, VB, or COBOL. We are finding most ISVs and consulting companies going with J2EE because they cannot control their customers' target platforms. We believe this application availability will result in J2EE beginning to dominate more and more as time goes on.

In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE. We feel the advantages outweigh those offered by Microsoft.NET. That is our preferred architecture, and we stand behind it.