Introduction to XML

XML stands for EXtensible Markup Language
XML is a markup language much like HTML
XML was designed to describe data
XML tags are not predefined. You must define your own tags
XML uses a Document Type Definition (DTD) or an XML Schema to describe the data
XML is a W3C Recommendation
The Main Differences between XML and HTML
XML was designed to carry data.
XML is not a replacement for HTML.XML and HTML were designed with different goals.
XML was designed to describe data and to focus on what data is.HTML was designed to display data and to focus on how data looks.
HTML is about displaying information, while XML is about describing information.

Characteristics of XML:
1. XML is Free and Extensible

XML tags are not predefined. You must "invent" your own tags.
The tags used to mark up HTML documents and the structure of HTML documents is predefined. The author of HTML documents can only use tags that are defined in the HTML standard (like

, , etc.).

XML allows the author to define his own tags and his own document structure.

The following example is a note to Tove from Jani, stored as XML:


Tove
Jani
Reminder
Don't forget me this weekend!


It is important to understand that XML was designed to store, carry, and exchange data. XML was not designed to display data.

2. XML can Separate Data from HTML
With XML, your data is stored outside your HTML.
When HTML is used to display data, the data is stored inside your HTML. With XML, data can be stored in separate XML files. This way you can concentrate on using HTML for data layout and display, and be sure that changes in the underlying data will not require any changes to your HTML.

3. XML is Used to Exchange Data
With XML, data can be exchanged between incompatible systems.
In the real world, computer systems and databases contain data in incompatible formats. One of the most time-consuming challenges for developers has been to exchange data between such systems over the Internet.
Converting the data to XML can greatly reduce this complexity and create data that can be read by many different types of applications
4. XML can be Used to Share Data
With XML, plain text files can be used to share data.
Since XML data is stored in plain text format, XML provides a software- and hardware-independent way of sharing data.

This makes it much easier to create data that different applications can work with. It also makes it easier to expand or upgrade a system to new operating systems, servers, applications, and new browsers
5. XML can be Used to Store Data
With XML, plain text files can be used to store data.
XML can also be used to store data in files or in databases. Applications can be written to store and retrieve information from the store, and generic applications can be used to display the data
6. XML Can Make your Data More Useful
With XML, your data is available to more users.
Since XML is independent of hardware, software and application, you can make your data available to other than only standard HTML browsers.
Other clients and applications can access your XML files as data sources, like they are accessing databases. Your data can be made available to all kinds of "reading machines" (agents), and it is easier to make your data available for blind people, or people with other disabilities.
7. XML can be Used to Create New Languages
XML is the mother of WAP and WML.
The Wireless Markup Language (WML), used to markup Internet applications for handheld devices like mobile phones, is written in XML.
XML Syntax Rules
1. XML documents use a self-describing and simple syntax.
2. All XML Elements Must Have a Closing Tag
3. XML Tags are Case Sensitive
4. XML Elements Must be Properly Nested
5. XML Documents Must Have a Root Element
6. XML Attribute Values Must be Quoted
XML Validation
1. Well Formed XML Documents

XML with correct syntax is Well Formed XML.
A "Well Formed" XML document has correct XML syntax.
A "Well Formed" XML document is a document that conforms to the XML syntax rules.
2. Valid XML Documents
XML validated against a DTD is Valid XML. A "Valid" XML document also conforms to a DTD. A "Valid" XML document is a "Well Formed" XML document, which also conforms to the rules of a Document Type Definition (DTD).

XML DTD

A DTD defines the legal elements of an XML document. The purpose of a DTD is to define the legal building blocks of an XML document. It defines the document structure with a list of legal elements.
A DTD can be declared inline inside an XML document, or as an external reference.
Internal DTD Declaration
If the DTD is declared inside the XML file, it should be wrapped in a DOCTYPE definition with the following syntax:

Example XML document with an internal DTD:

< !a DOCTYPE note [





]>

Tove
Jani
Reminder
Don't forget me this weekend

The DTD above is interpreted like this:!DOCTYPE note defines that the root element of this document is note.!ELEMENT note defines that the note element contains four elements: "to,from,heading,body".!ELEMENT to defines the to element to be of the type "#PCDATA".!ELEMENT from defines the from element to be of the type "#PCDATA".!ELEMENT heading defines the heading element to be of the type "#PCDATA".!ELEMENT body defines the body element to be of the type "#PCDATA".
External DTD Declaration
If the DTD is declared in an external file, it should be wrapped in a DOCTYPE definition with the following syntax:

This is the same XML document as above, but with an external DTD:



Tove
Jani
Reminder
Don't forget me this weekend!

And this is the file "note.dtd" which contains the DTD:






Why Use a DTD?
With a DTD, each of your XML files can carry a description of its own format. With a DTD, independent groups of people can agree to use a standard DTD for interchanging data.
Displaying XML with CSS
With CSS (Cascading Style Sheets) you can add display information to an XML document.

Displaying XML with XSL
XSL is the preferred style sheet language of XML. XSL (the eXtensible Stylesheet Language) is far more sophisticated than CSS.

Mobile VoIP

Mobile VoIP is the application of Voice over IP technology to mobile handsets.

There are several methodologies by which a mobile handset can be integrated into a VoIP network. One implementation turns the mobile device into a standard SIP client, which then uses a data network to send and receive SIP messaging, and to send and receive RTP for the voice path. This methodology of turning a mobile handset into a standard SIP client requires that the mobile handset support, at minimum, high speed IP communications. In this application, standard VoIP protocols (typically SIP) are used over any broadband IP-capable wireless network connection such as EVDO rev A (which is synchronously high speed - both high speed up and down), HSDPA, WiFi or WiMAX.

Another implementation of mobile integration uses a softswitch like gateway to bridge SIP and RTP into the mobile network's SS7 infrastructure. In this implementation, the mobile handset continues to operate as it always has (as a GSM or CDMA based device), but now it can be controlled by a SIP application server which can now provide advanced SIP based services to it. Several vendors offer this kind of capability today, including Tango Networks, Outsmart, NewStep, BridgePort and BroadSoft.

Mobile VoIP will require a compromise between economy and mobility. For example, Voice over Wi-Fi offers potentially free service but is only available within the coverage area of a Wi-Fi Access Point. High speed services from mobile operators using EVDO rev A or HSDPA may have better audio quality and capabilities for metropolitan-wide coverage including fast handoffs among mobile base stations, yet it will cost more than the typical Wi-Fi-based VoIP service.

Mobile VoIP will become an important service in the coming years as device manufacturers exploit more powerful processors and less costly memory to meet user needs for ever-more 'power in their pocket'. Smartphones in mid-2006 are capable of sending and receiving email, browsing the web (albeit at low rates) and in some cases allowing a user to watch TV.

The challenge for the mobile operator industry is to deliver the benefits and innovations of IP without losing control of the network service. Users like the Internet to be free and high speed without extra charges for visiting specific sites. Such a service challenges the most valuable service in the telecommunications industry - voice - and threatens to change the nature of the global communications industry.


Mobile VoIP relies on two main technologies:

UMA - the Unlicensed Mobile Access Generic Access Network, designed to allow VoIP to run over the GSM cellular backbone
SIP - the standard used by most VoIP services, and now being implemented on mobile handsets

VoIP Mobile industry is estimated to grow to 12 Billion Dollars by 2010 in Europe alone. Four technologies are required for mobile VoIP functionality: a device, client software, a wireless network and a VoIP service.

Throughout the early 2000s, Hewlett-Packard, Symbol Technologies and others have been innovators in Wi-Fi-based handheld devices, as Personal digital assistant or handheld computers for warehousing and other applications. As successive generations of these devices gained in processing power and battery life, their potential use as a platform for mobile VoIP became practical. Using Microsoft Windows CE operating systems, in the summer of 2005 companies delivered practical client software to run on these class of Wi-Fi only, Windows-based PDAs.

In the summer of 2006, a SIP (Session Initiation Protocol) stack was introduced and a VoIP client in the E-series dual-mode Wi-Fi handsets (Nokia E60, Nokia E61, Nokia E70).

From a Wi-Fi network perspective there are several innovations, embedded in the most current vendor Wi-Fi networking equipment for the enterprise and municipal service provider, that makes them particularly powerful in a mobile VoIP context. These innovations include support for strong encryption making the conversation in a Wi-Fi context quite private (IEEE 802.11i), support for Quality of Service for real-time services such as mobile VoIP (see IEEE 802.11e) and in some cases support for wireless access point to access point call handoff.

VoIP server vendors, upon which VoIP service providers create the service have announced support for integrating mobile handsets into VoIP infrastructures, either natively using SS7 interfaces into the mobile network, or via software based clients running on the mobile handset. BroadSoft is one such vendor of a platform (BroadWorks) that enables mobile integration using either strategy. Enterprise IP PBX vendors have developed, tested and announced capabilities for mobile VoIP users interacting with their business IP-based phone systems.

One implementation of Fixed mobile convergence enables seamless roaming between WIFI and GSM or CDMA networks. Standards and alliances have been developed and technologies have been demonstrated as early as December 2005. Cisco and FirstHand Technologies demonstrated a Wi-Fi to GSM handoff in San Jose, December 5, 2005.

WiFiMobile, founded in 2002 were one of the first mobile VoIP providers with their own self developed VoIP client compatible with all Nokia E and Nseries smartphones.

Recently T-Mobile blocked the access to pure mobile VoIP numbers, which were issued by Truphone for the first time. The issue was widely discussed in the press and although Truphone won an injunction[1], the case is still in the courts while T-Mobile pay only a nominal termination fee.

IP aDDRESS

Every device connected to the public Internet is assigned a unique number known as an Internet Protocol (IP) address. IP addresses consist of four numbers separated by periods (also called a 'dotted-quad') and look something like 127.0.0.1.

Since these numbers are usually assigned to internet service providers within region-based blocks, an IP address can often be used to identify the region or country from which a computer is connecting to the Internet. An IP address can sometimes be used to show the user's general location.

Because the numbers may be tedious to deal with, an IP address may also be assigned to a Host name, which is sometimes easier to remember. Hostnames may be looked up to find IP addresses, and vice-versa. At one time ISPs issued one IP address to each user. These are called static IP addresses. Because there is a limited number of IP addresses and with increased usage of the internet ISPs now issue IP addresses in a dynamic fashion out of a pool of IP addresses (Using DHCP). These are referred to as dynamic IP addresses. This also limits the ability of the user to host websites, mail servers, ftp servers, etc. In addition to users connecting to the internet, with virtual hosting, a single machine can act like multiple machines (with multiple domain names and IP addresses).

Knowing your IP address can allow you (and others you tell) to access services running on your machine such as online games, servers (FTP, web, mail), and remote access utilities (PCAnywhere, GoToMyPC, MS Remote Desktop

PHP greatest security-SESSION SECURITY

1. Shared web servers
anyone else on the server can read your session files (typically in the /tmp directory) if PHP is running as an Apache module (so the session files belong to the web user) and possibly when PHP is used as a CGI (depending on how sessions are implemented).

Someone browsing the session files (probably) won’t know the site the server the sessions apply to (so may not be able to use a username / password combination they found) but you may still be putting sensitive info (like credit card details) somewhere for all to see. Plus they’ve got a list of valid session IDs…

If you’re just storing passwords in the session, you can get away with this by using md5() (preferably twice) to one-way encrypt the password. This does not help though if you need to recover the value of a session variable.
Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache). If it gets to very high traffic, it’s time to think about getting your own server…

2. XSS exploits (and session hijacking) - using JavaScript users can be fooled into giving away their active session_id.

All someone needs to “hijack” a session is the unique session id. It’s like the key to a railway station locker. The locker doesn’t check you’re the valid owner of the key, before allowing you to open it so anyone with the key can get in.

Research XSS and how to prevent it.

Accept that session hijacking cannot be entirely prevented (checks on IP address, for example, is foiled by AOL, who assign a new client IP on more or less every page request) so double check “critical actions” a user can perform when logged in e.g. when changing password - require the old password, which the session hijacker will (hopefully) not know. Displaying credit card information - do like Amazon and only display the last four digits. Basically limit the damage someone can do if they hijack a session.

3. Session IDs in URL (and hijacking) - if you’re using session IDs in the URL (as opposed to a session cookie), make sure off site links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to eliminate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts).

Ideally, don’t pass session ids in the URL - require users to accept a cookie if they need to “log in”.

4. Session Fixation (pre-hijacking)
If you assign a session to a visitor to your site, before they are logged in (for example for click path analysis), make sure that you assign them a new session id when they do login, so that if someone pre-generated the initial session id for them, they won’t get the new ID.

For PHP 4.2.0+, see session_regenerate_id() (in particular the user submitted comments). For PHP < 4.2.0, you'll have to destroy the session and re-create it when the user logs in, carrying any stored data between the two. The session_id() function may also be useful (haven’t explored it in this context myself).

5. Sniffing Packets (use SSL [HTTPS]) - a session ID can be “sniffed” between the client and your server. If it’s a site where money is changing hands or other sensitive personal information is involved, SSL is a requirement.

Otherwise, without SSL, you have to live with the risk (just like you do every time you use that FTP client…).

6. Cookies are not for session data - on a related note, don’t use cookies for store sensitive information.

Cookie data, unlike sessions, gets stored on the client site. Apart from the “sniffing risk”, a large majority of Windows users have little idea of security and may be “owned by haxor”.

Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistence (e.g. “Remember Me”) rather than “active session” persistence.

Musical Instrument Digital Interface (MIDI)

The development of the MIDI system has been a major catalyst in the recent unprecedented explosion of music technology. MIDI has put powerful computer instrument networks and software in the hands of less technically versed musicians and amateurs and has provided new and time-saving tools for computer musicians. The system first appeared in 1982 following an agreement among manufacturers and developers of electronic musical instruments to include a common set of hardware connectors and digital codes in their instrument design. The original goal was to interface instruments of different manufacture to control common functions, such as note events, timing events, pitch bends, pedal information, etc. Though several classes of codes have been added to the MIDI 1.0 Specification (International MIDI Association, 1989) and MIDI applications have grown far beyond the original intent, the basic protocol has remained unchanged. MIDI is a system very much like a player piano roll in that it is used to specify the actions of a synthesizer or other electronic devices, while the tone or effect is generated by the instrument itself.

file transfer protocol (FTP)

File Transfer Protocol, or FTP, is a protocol used for transferring files from one Internet location to another. FTP is the preferred method of exchanging files, because it's faster than other protocols like HTTP. FTP is the method by which you'll upload files into your webhosting account. FTP data is sent and received through port 21. The transfer is asynchronous, and therefore faster.The Original Objectives of FTP are:1. To promote sharing of files (computer programs and/or data),2. To encourage indirect or implicit (via programs) use of remote computers,3. To shield a user from variations in file storage systems among hosts, and4. To transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.First defined in RFC 172 written in June 1971, the protocol has been through several changes through to the current specification, which is defined in RFC 959. It's worth looking at its basic operation to get a better understanding of how content switching can improve performance and reliability in FTP environments.

HTTP

HTTP stands for Hypertext Transfer Protocol. It's the network protocol used to deliver virtually all files and other data (collectively called resources) on the World Wide Web, whether they're HTML files, image files, query results, or anything else. Usually, HTTP takes place through TCP/IP sockets (and this tutorial ignores other possibilities).A browser is an HTTP client because it sends requests to an HTTP server (Web server), which then sends responses back to the client. The standard (and default) port for HTTP servers to listen on is 80, though they can use any port.