| HOME | Wireless Technology | Mobile / Wireless Computing | Software Languages |
WML - An Introduction The Wireless Markup Language is a simple markup language that was designed exclusively for the purpose of creating applications to be sent over wireless networks to WAP - enabled mobile devices. WML is an open standard and was developed by the WAP forum and the WML specification forms a part of the broader WAP specification. WML is an application of XML. WML has some distinct differences from other markup languages, for instance HTML. WML looks quite like HTML, but there is a significant difference between them. HTML is mainly used for creating documents, which in turn are being designed to display information. But WML is being used for creating applications, which are designed for user interaction. There is one more important difference. Basically Web contents are being accessed from powerful desktop computing systems that have bigger displays and fast, cheap, reliable wired network connections. The web browser is a sophisticated software package that offers a number of flexible and convenient features for the viewers. But wireless network connections are unreliable, slow and expensive and the micro browsers that are fitted in WAP-enabled mobile devices have very small displays, which in a way makes receiving and sending information inconvenient. Considering the limitations of mobile devices and the wireless networks, WML has to be designed in such a way that it offsets many of those limitations. Also mobile communication, being expensive, the mobile users would visit sites seeking specific pieces of information and like to get them very quickly. WML meets these requirements quite successfully and brings a high degree of interaction with users. The Structure of a WML ApplicationCards and Decks are the two main parts in an WML application. WML approaches the above-mentioned needs by removing the idea of a page, which we have in the Web. Instead, WML applications are composed of one or more decks, which are containers of collections of cards. Each card typically contains some content, such as text and images that are displayed to the user, and some other content that is used by the micro browser to control how the user moves from one card to the next. Also a card may contain input fields for the user to ender data as we have the form functionality using HTML in web browsers. WAP-enabled devices will display a single card at a time. If a card is too large to fit the display all at once, the device may split the card and show it as a sequence of screens or use use some mechanism such as scroll bars. Normally a WML card is similar to an HTML page, but there is no way in HTML for bundling a collection of pages together. This distinct facility being offered by WML decks is more important for wireless Internet applications. That is, by combining related cards, several cards can be sent to microbrowsers at the same time. This has the potential of saving a great deal of time and by designing applications intelligently, it is feasible to reduce the number of decks to be passed to devices. If deck is too large, the wireless application developer has to split it up in the most logical way. One has to play off the benefits of having many cards on the WAP-enabled device at once against the time for a very large deck to travel from content server to mobile devices.
Since WML is an application of XML, it has to start with a document prolog. The prolog states that the particular WML belongs to which version of XML and the gives the location of the document type definition against which this document will be validated. The document type declaration tells that the root element in a WML document will be
As it is a wireless network, the data transfer size has to be very minimum. Towards this, WML documents from the content server have to be compiled into smaller binary file. This process of compilation is being accomplished by the intermediate WAP Gateway. The compiled binary file is called WAP binary XML (WBXML). The compilation of WML files is mostly a process of tokenization, in which the names of the tags and elements in the WML files are replaced by predefined, single-character codes. This technique drastically reduces the size of each WML document. When the compiled deck reaches the microbrowser, the reverse process has to be done by the microbrowser to bring the original document in the content server.
White Space is a generic term for characters in a WML code that serve to break it up visually, but has no meaning as far as WML is concerned. White space represents spaces, tabs, line breaks, and so on. WML follows the XML rules as far as white space is concerned. The rule recommends to ignore it before and after an element and to compress all other sequences of white spaces into a single space space between two words. This process reduces the total number bytes of a WML application. Thus compilation process actually means applying this rule about white space as it proceeds. The other important feature is that WML supports inserting comments in the code. They start with the sequence ''. The comments will not be displayed in the microbrowsers.
There are two more possibilities to extend a WML file. They are adding more elements to the existing deck or adding attributes to the elements that already exist. In WML, there are three attributes that can be used with almost all elements: xml:lang, class and id. The first one is xml:lang and this attribute is optional. Its value defines the human language of any data that may be presented to the user, so that user agent can modify its behavior if there is a need for the displaying purpose.
By specifying a class attribute with the same value in several different elements, these elements can be made part of the same class. This feature does not make any impact on the microbrowser or to the users of that WML application. But this feature can be used by some external program that was asked to process the decks present in the WML application.
The id attribute is used to provide an element with a unique name within a single deck. The id attribute specifies a name for a card. This feature is necessary if there is more than one card in the deck. When users want to navigate from one card in the deck to another, there should be a mechanism to differentiate the cards.
Below we are see some of the elements that a card may contain.
Paragraphs - To have a formatted text in the user screen, a text can be broken into paragraphs. The paragraph element has align attribute, whose value may be center, right or left. Also the paragraph element has mode attribute, whose value may be wrap and nowrap.
All the text in the cards of an WML application has appeared faithfully in the microbrowser to be viewed by the users. But there are some characters that are intended to convey very specific information to the microbrowser and not for users consumption. For instance '<' in a code like x < y + z.
Here microbrowsers on encountering the < character will look for a closing tag. But there is no closing tag and this will result in error as WML is very strict about the tag rules as WML is an application of XML. Actually '<' is a reserved character in WML. There are two kinds of ways for outputting such kinds of reserved characters. They are numeric character entities and named character entities.
Numeric Character Entities are actually an alternative means of expressing any character, not just reserved ones. Every character that may be displayed has a number associated with it and by referring to that number in a WML code, one can make the corresponding character to be displayed. The numbers that WML uses to represent characters are borrowed from Unicode.
Named Character Entities work in broadly the same way as numeric ones. They are not defined for all characters and serve as an easy way to remember the representations of some of the reserved characters the developers have to display often. This representation makes the WML code easier to read. The above code can be displayed using x < y + z.
Line Breaks - Different WAP-enabled devices have different screen sizes and even if they use the same microbrowser, there is no guarantee that the applications will look the same. This is because of the fact that number of characters per line is varying according to the screen size. This makes the sentences and paragraphs to wrap in a different manner. Also there may be occasions, such as forcing a line break between two words, preventing line break from occurring between two words or enforcing a word to be split across two lines. The <br> element is used to force a line break between two words in a paragraph. <br> element has no content and it is always empty.
The non-breaking space character entity ; is used to prevent a line break between two words. The last layout control is character entity, which is used to add a discretionary hyphen. This means that the microbrowser may add a line break at its location and if it does, it should also add a hyphen.
There are controlling elements in WML for manipulating the appearance of content. The <b> element is used to make text use a bold font, while the <i> element is used to italicize text. The <em> element makes the text emphasized. There are some other controls such as <small>, <strong>, <big> to facilitate distinguishing text contents.
Thus adding and formatting text-based content can be accomplished through the use of paragraphs, elements and entities.
Uniform Resource Locators (URLs) are being used to name resources in WML. There are two different types of URLs: absolute and relative URLs. A WML fragment anchor is specified by suffixing the URL for a deck with a # symbol and the destination element's id attribute is added as follows:
deck-url#card-id
For example, if we want to refer to the "menu" card in mydeck, we have to use an absolute URL such as
http://www.peterindia.net/mydeck.wml#menu.
The element is the simplest way in WML of creating an anchor that links one document to another. elements have a number of attributes that can be used to configure and customize their behavior. Apart from the common attributes
xml:lang, id and class, the <a> element supports attributes called href, title and
access key. href is used to specify the destination of a hyperlink. The destination may be within a deck, or a card in another deck that is also on the same site or the card may be in a deck which is on another site. For the first case, it is simply a matter of specifying the id of the destination card as the value of
href. For the second one, we have to specify the URL for the deck and the id attribute of the desired card element within that deck. For the last case, the destination has to be specified fully with a full URL, the server name, the deck to load and the card within the deck.
The <a> element's title attribute is used to provide a brief description of the hyperlink. The accesskey attribute allows the user to select an anchor by pressing a key on the keypad of the WAP-enabled device. The accesskey attribute's values are the numbers, which appear on the left side of the hyperlinks. Pressing those keys will result immediate navigation.
The <anchor> element supports the same attributes with the same semantics as
, with the exception of href. It performs straightforward navigation. This element can be used together with elements called <go> and <prev> to specify a destination for the hyperlink.
The <go> element is used to specify a navigation action that occurs as a result of an event. The <go> supports a number of attributes. When used with the <anchor> element to perform simple navigation, the <go> element has the following general form:
<anchor>
The <anchor> element offers the ability to navigate to the previous card. This is being achieved by the <prev> element.
To be concluded
|
|||
Click for 