CMT3315 LAB04 - XML Syntax 2

Today's post introduces Document Type Definition (DTD) syntax and answers a number of questions relating to XML syntax and DTDs.

Document Type Definition

In last week's post we created the following XML document containing information about a small music collection:

   <?xml version="1.0" encoding="UTF-8"?>
   <DOCTYPE musicCollection>
   <!--Prolog ends here. -->
   <musicCollection>
      <cd index="1">
         <title>Innuendo</title>
         <artist>Queen</artist>
         <tracks>
            <track id="1">Innuendo</track>
            <track id="2">I'm Going Slightly Mad</track>
            <track id="3">Headlong</track>
            <track id="4">I Can't Live With You</track>
            <track id="5">Don't Try So Hard</track>
            <track id="6">Ride The Wild Wind</track>
            <track id="7">All God's People</track>
            <track id="8">These Are The Days Of Our Lives</track>
            <track id="9">Delilah</track>
            <track id="10">The Hitman</track>
            <track id="11">Bijou</track>
            <track id="12">The Show Must Go On</track>
          </tracks>
      </cd>
      <cd index="2">
         <title>(What's The Story) Morning Glory?</title>
         <artist>Oasis</artist>
         <tracks>
            <track id="1">Hello</track>
            <track id="2">Roll With It</track>
            <track id="3">Wonderwall</track>
            <track id="4">Don't Look Back In Anger</track>
            <track id="5">Hey Now!</track>
            <track id="6">Untitled</track>
            <track id="7">Some Might Say</track>
            <track id="8">Cast No Shadow</track>
            <track id="9">She's Electric</track>
            <track id="10">Morning Glory</track>
            <track id="11">Untitled</track>
            <track id="12">Champagne Supernova</track>
          </tracks>
      </cd>
   </musicCollection>

XML uses documents known as schemas to define the structure a particular class (type) of XML document should follow. In our example, Line 2 specifies that this document is of type musicCollection. We can use a Document Type Definition (DTD) to define the legal structure of the musicCollection document type. Looking at our example we can see that every "cd" element is expected to have a "title", an "artist" and a "tracks" element. In turn, the "tracks" element further contains multiple "track" elements. The number of occurences of an element is known as it's Cardinality. In a DTD, we can define what which elements are expected as well as their attributes, sequence and cardinality.

Using this information we can write our DTD, starting from the root element:

<!--musicCollection.dtd-->
<!ELEMENT musicCollection (cd+)>

This is the first line in our DTD document. It specifies that the "musicCollection" document element is made up of one or more "cd" elements. The "+" sign after "cd" specifies the "one or more" cardinality of the "cd" element. Other Cardinality specifiers include:

• ? - means 0 or 1
• * - means 0 or 1 or more
• no specifier means "exactly 1"

Let's define the "cd" element next:

<!--musicCollection.dtd-->
<!ELEMENT musicCollection (cd+)>
<!ELEMENT cd (title, artist, tracks)>
<!ATTLIST cd index CDATA #REQUIRED>

The "cd" element is made up of the "title", "artist" and "tracks" elements. Given that each of these must appear only once in a "cd" element, no cardinality specifier was necessary. Additionally, the "cd" element has an "index" attribute which is defined at line 4. We also specify that the "index" attribute is made up of character data (CDATA) and is required (#REQUIRED). CDATA is not treated as markup by the XML parser and will not be parsed. Let's add the rest of our elements:

<!--musicCollection.dtd-->
<!ELEMENT musicCollection (cd+)>
<!ELEMENT cd (title, artist, tracks)>
<!ATTLIST cd index CDATA #REQUIRED>
<!ELEMENT title (#PCDATA)>
<!ELEMENT artist (#PCDATA)>
<!ELEMENT tracks (track+)>
<!ELEMENT track (#PCDATA)>
<!ATTLIST track id CDATA #REQUIRED>

Our DTD is now complete. Each of the "title", "artist" and "track" elements are defined as containing parsed character data (#PCDATA). In contrast to CDATA, PCDATA is text that will be parsed by the parser. We also specify that the "tracks" element should contain multiple "track" elements and that every "track" element must have an "id" attribute. All we need to do now is reference our DTD from the XML document. Assuming that our DTD file is called "musicCollection.dtd" and resides in the same directory as the XML file, the following modification to the XML's document type declaration will reference the DTD:

<DOCTYPE musicCollection SYSTEM "musicCollection.dtd">

Summary

DTDs can be declared inside of the XML document itself or as external files and are a simple yet effective way of defining and validating the structure of XML documents.

The following are the questions for this week's lab session

Quick Questions

Q1. What does XML stand for?  And CSS?

XML stands for Extensible Markup Language and CSS stands for Cascading Style Sheets.

Q2. Is this XML line well-formed? Say Why.

<b><i>This text is bold and italic </i></b>

Yes this line is well formed.  Both start tags match their end tags and are properly nested.

Q3. Is this XML document well-formed? Say why.

<?xml version= "1.0" ?>
<greeting>
Hello, world!
</greeting>
<greeting>
Hello Mars too!
</greeting>

No. This XML document is not well formed as it does not have a root element.

Longer Questions

Q1. Write an XML document that contains the following information:

• The name of this course;
• The name of this building;
• The name of this room;
• The start and end times of this session.

Choose appropriate tags.  Use attributes for the start and end times.

<?xml version= "1.0" ?>
<course>
 <name>CMT 3315 Advanced Web Technologies</name>
 <buildingName>STC Training</buildingName>
 <roomName>Room 5</roomName>
 <session startTime="18:00" endTime="21:00"/>
</course>

Q2. Identify all the syntax errors in the following XML document:

<?xml version= "1.0" ?>
<!DOCTYPE bookStock SYSTEM "bookstock.dtd">
<bookstore>
  <book category="Cooking">
    <title lang="en">Everyday Italian</title>
    <author>Giada De Laurentiis</author>
    <1stEdition>2005</1stEdition >
    <2ndEdition>2007</2ndEdition >
    <price>19.99</price currency="pounds sterling">
  </book>
  <book category="Children’>
    <title lang="en">Harry Potter and the enormous pile of money</title>
  <!—best selling children’s book of the year --2009 -->
    <author>J K. Rowling</author>
   <1stEdition>2005</1stEdition>
    <price>29.99</Price>
  </book>
  <book category="Web">
    <title lang="en">Learning XML</title>
    <author>Erik T. Ray</author>
   <1stEdition>2003</1stEdition>
   <2ndEdition >2008</2ndEdition >
    <price>29.95</discount>
    <discount>15%</price>
  </book>
  <book category="Computing">
    <title lang=en>Insanely great – the life and times of Macintosh, the computer that changed everything </title>
    <author <!—other authors not listed -->>Steven Levy</author>
   <1stEdition>1994</1stEdition>
    <price>9.95</discount>
    <discount>15%</price>
  </book>

The XML document contains various syntax errors including:

• The root node should be called "bookStock" as specified in the DOCTYPE declaration. There is also no matching closing tag;
• The "1stEdition" and "2ndEdition" element names are invalid as names cannot start with a number (lines 7, 8, 15, 21, 22, 29);
• Attribute placed in the end tag at line 9. This should be placed in the start tag;
• Mismatching quote at line 11;
• Incorrect comment start tag and extra "--" in comment on line 13;
• Mismatching start and end tags at lines 16, 23, 24, 30 and 31;
• Missing quotes for attribute value at line 27;
• Comment incorrectly placed within the start tag at line 28.  Comment start tag is also incorrect;

Q3. You are asked to produce a Document Type Declaration for a class of XML documents called “memo”. You come up with this .dtd file:

<!DOCTYPE memo
[
<!ELEMENT memo (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>

Your client says “That’s all very well, but every memo has to have a date. And some of them have to have a security classification too (you might want to write “Secret” at the top). And a memo has a serial number – I think that’s what you’d call an attribute, isn’t it?” How would you amend this .dtd file so that it did what the client wanted?

A suitable DTD to fulfill these requirements would be as follows:

<!DOCTYPE memo
[
<!ELEMENT memo (date,to,from,heading,body,classification?)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT classification(#PCDATA)>
<!ATTLIST memo serialNo ID #REQUIRED>
]>

Given that not all memos will have a security classification, the DTD uses the "?" cardinality specifier to indicate that the "memo" element can contain zero or one "classification" element.

Other specifiers include:

• "*" - means zero or one or more of the element is allowed
• "+" - means that one or more of the element is allowed

Finally, attaching none of the cardinality specifiers to an element name means that the element must appear exactly once.

Readmore...

CMT3315 Lab 03 - XML Syntax 1

Today's post introduces the basics of XML syntax and answers a number of questions related to this topic.

XML document structure & syntax

The basic idea behind XML is to produce documents whose structure can be understood by software applications. In an XML document, pieces of text that have special meaning are marked up using tags. A tag is simply a word between angle brackets such as "<name>". An XML document is made up of 3 parts:

• A prolog (optional);
• The document or root element;
• Other miscellaneous content following the root element end tag.(optional)

The prolog is an optional component of an XML document which, if included, must appear before the root element. The prolog consists of an XML declaration, which defines the XML version and character encoding being used, and a Document Type Declaration (DTD). The prolog may also contain comments. Here's an example of an XML prolog:

   <?xml version="1.0" encoding="UTF-8"?>
   <!--This is a comment-->
   <DOCTYPE musicCollection"<

Lines 1 and 2 are the XML declaration and a comment respectively. Line 3 is the Document Type Declaration which provides the name of the document element "musicCollection". The document or root element follows the prolog. An XML document must have only one root element which in many cases contains a heirarchy of other elements. For instance, let's assume that our music collection is made up of a number of CDs where each CD has a title, an artist and a number of tracks. A suitable XML document to store this information would be:

   <?xml version="1.0" encoding="UTF-8"?>
   <DOCTYPE musicCollection>
   <!--Prolog ends here. -->
   <musicCollection>
      <cd index="1">
         <title>Innuendo</title>
         <artist>Queen</artist>
         <tracks>
            <track id="1">Innuendo</track>
            <track id="2">I'm Going Slightly Mad</track>
            <track id="3">Headlong</track>
            <track id="4">I Can't Live With You</track>
            <track id="5">Don't Try So Hard</track>
            <track id="6">Ride The Wild Wind</track>
            <track id="7">All God's People</track>
            <track id="8">These Are The Days Of Our Lives</track>
            <track id="9">Delilah</track>
            <track id="10">The Hitman</track>
            <track id="11">Bijou</track>
            <track id="12">The Show Must Go On</track>
          </tracks>
      </cd>
      <cd index="2">
         <title>(What's The Story) Morning Glory?</title>
         <artist>Oasis</artist>
         <tracks>
            <track id="1">Hello</track>
            <track id="2">Roll With It</track>
            <track id="3">Wonderwall</track>
            <track id="4">Don't Look Back In Anger</track>
            <track id="5">Hey Now!</track>
            <track id="6">Untitled</track>
            <track id="7">Some Might Say</track>
            <track id="8">Cast No Shadow</track>
            <track id="9">She's Electric</track>
            <track id="10">Morning Glory</track>
            <track id="11">Untitled</track>
            <track id="12">Champagne Supernova</track>
          </tracks>
      </cd>
   </musicCollection>

Above we can see that our "musicCollection" root element contains two "cd" elements which in turn contain further elements describing the CD. We can also see that every start tag has a matching end tag (e.g. "<cd>" and "</cd>"). XML elements can have zero, one or more child elements and all (except for the root element) must have a parent element. Furthermore, XML elements must be correctly nested for the document to be valid. Elements in XML can also contain attributes and when present, these should be placed withn the element's start tag. In our example, every "cd" element has an attribute called "index" and every "track" element has an attribute called "id". XML attributes can be thought of data describing data, generally (but not necessarily) used for storing ID's. An attribute is made up of a name, followed by an "=" sign and a value within quotes, which may be single or double as long as they match. We can use this example as a basis for discussing the next section:

Well Formedness

A well formed XML document is one that follows proper XML syntax. Unlike most HTML parsers, XML parsers expect the document to be well formed and will stop processing the document if any syntax errors are found. An XML document must be structured as discussed in the previous section and all element and attribute names must be valid. The first character in a name must be either a letter ([A-Z][a-z]) a colon ":" or an underscore "_" and the name cannot start with the letters "xml". The rest of the characters can also include numbers ([0-9]), dashes "-" and fullstops ".".

XML is case-sensitive so using our example above, the element "<track>" is not the same as the element <Track>. Furthermore, end tags must match their start tags. In some cases, XML elements will not contain any information. In such cases the end tag may be replaced by a "/" at the end of a start tag, for example:

 <emptyElement> index="0" />
 <!-- is equivalent to -->
 <emptyElement> index="0"><emptyElement>

These are the basic rules to follow to create a well formed XML document.

Lab Questions

Q1. Write an XML document that contains the following information:

• Your name;
• Your email address;
• Your student number;
• Your home town;
• Your date of birth.

Choose appropriate tags. Use attributes for the date of birth.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE student>
<student dateOfBirth="01/01/1990">
 <name>Wayne Zammit</name>
 <email>wayne@somedomain.com</email>
 <studentNo>NN123</studentNo>
 <homeTown>St. Julians</homeTown>
</student>

Q2. Identify all the syntax errors in the XML document below:

<?xml version= "1.0" ?>
<!DOCTYPE countryCollection SYSTEM "countryList.dtd">
<CountryList>
<Nations TotalNations ="3"/>
<!--Data from CIA --Year Book -->
 <Country CountryCode="1"> 
  <OfficialName>United States of America</officialName>
  <Label>Common Names:</label>  
  <CommonName>United States</commonName>
  <CommonName>U.S.</commonName>
  <Label>Capital:</capital>  
  <Capital cityNum="1">Washington, D.C. </label>
  <2ndCity cityNum="2">New York </2ndCity> 
  <Label>Major Cities:</label> 
  <MajorCity cityNum="3">Los Angeles </majorCity>
  <MajorCity cityNum="4">Chicago </majorCity>  
  <MajorCity cityNum="5’>Dallas </majorCity>  
  <Label>Bordering Bodies of Water:</label>    
  <BorderingBodyOfWater> Atlantic Ocean </borderingBodyOfWater>
  <BorderingBodyOfWater> Pacific Ocean </borderingBodyOfWater>  
  <BorderingBodyOfWater> Gulf of Mexico </borderingBodyOfWater> 
  <Label>Bordering Countries:</label>   
  <BorderingCountry CountryCode="1"> Canada </borderingCountry>    
  <BorderingCountry CountryCode ="52"> Mexico </borderingCountry>
</country>
 <Country CountryCode="81">
  <OfficialName> Japan </officialName>
  <Label>Common Names:</label>    
  <CommonName> Japan </commonName>
  <Label>Capital:</label>  
  <Capital>Tokyo</capital cityNum="1">
  <2ndCity cityNum="2">Osaka </2ndCity>
  <Label>Major Cities:</label>    
  <MajorCity cityNum="3">Nagoya </majorCity>
  <MajorCity cityNum="4">Osaka </majorCity>  
  <MajorCity cityNum="5’>Kobe </majorCity>  
  <Label>Bordering Bodies of Water:</label>
  <BorderingBodyOfWater>Sea of Japan </borderingBodyOfWater>
  <BorderingBodyOfWater>Pacific Ocean </borderingBodyOfWater>  
 </country>
 <Country CountryCode="254">
  <OfficialName> Republic of Kenya </officialName>
  <Label>Common Names:</label>    
  <CommonName> Kenya </commonName>
  <Label>Capital:</label>  
  <Capital cityNum=’1’>Nairobi </capital>
  <2ndCity cityNum=’2’>Mombasa</2ndCity>
  <Label>Major Cities:</label>    
  <MajorCity cityNum=’3’>Mombasa </majorCity>
  <MajorCity cityNum=’4’>Lamu </majorCity>
  <MajorCity cityNum=’5’>Malindi </majorCity>  
  <MajorCity cityNum=’6’ cityNum=’7’>Kisumu-Kericho </majorCity> 
  <Label>Bordering Bodies of Water:</label>
  <BorderingBodyOfWater <!--Also Lake Victoria --> > Indian Ocean </borderingBodyOfWater>
 </country> 

The XML document contains various syntax errors including:

• The root node should be called "<countryCollection>" as specified in the DOCTYPE declaration.  There is also no matching closing tag;
• The comment at line 5 contains an extra "--" between its start and end tags.  This is not allowed;
• Start tags do not match end tags (different letter-casing) and in some instances (eg lines 11 and 12) end tags have been swapped;
• The "2ndCity" element name is invalid as names cannot start with a number (lines 13, 32, 47);
• Mismatching quote at lines 17 and 36;
• Attribute placed in the end tag at line 31.  This should be placed in the start tag;
• Single quotes used to enclose attribute values at lines 46 to 52;
• Duplicate attribute "cityNum" at line 52;
• Comment placed within the start tag at line 54;

Readmore...

CMT3315 LAB 02 - XML vs HTML

In this post we will be having a look at the similarities and differences between XML and HTML. As discussed in my previous post XML is a subset of SGML designed to make the knowledge structure of a document known to a software package. In essence, it enables a software package to "understand" the structure of a document. HTML was also derived from SGML but appeared before XML.

HTML

HTML is made up of a standard set of tags specifically designed to create web pages meant to be understood and displayed by web browsers. Soon after its original release, HTML became very popular very quickly and web pages were being used to accomplish things that they weren't designed to do. Initally, the way an HTML document was interpreted and displayed was left entirely up to the browser. This started creating problems to web designers who wanted their pages to render the same across browsers, so HTML started being extended with other tags that defined presentation such as "<font>". These type of tags go directly against the original concept of SGML which was to separate content from layout. The browser wars did little to help the situation, and in fact made it even worse. Fierce competition gave rise to proprietary tags, and browsers became tolerant to badly written HTML documents which in the end badly hinders programmatic interpretation of web pages.

XML

A major advantage of HTML is its simplicity but it is also one of its biggest weaknesses. XML was born out of the need for having something that was simpler than SGML but alsostricter than HTML. XML tags are user-defined, which means that when creating an XML document you are defining your own standard for structuring that particular type of document. That is why XML is extensible. Every time you define a new set of tags you are effectively defining a new markup language! In fact, just like SGML, XML is itself a framework for defining markup languages. Its main objective is providing the ability to structure information in such a way as to enable any system on any platform to process that information.

XML gave rise to XHTML, a stricter version of HTML based on XML rules. Differences between HTML and XHTML include:

• unlike HTML, XHTML documents must be well-formed XML documents;
• XHTML is case-sensitive for element and attribute names, HTML is not;
• Attribute minimisation (omitting the "=" sign and value) in XHTML is not allowed.

There are many more differences, most of which would require a separate blog post to explain, but the main idea is that XHTML addresses the limits and weaknesses in the original HTML specification because it is based on XML.

Summary

HTML (1990) was derived from SGML (1986) as a simpler markup language for creating hyperlinked web documents. XML (1998) is a specification for defining markup languages simpler than SGML from which it is itself derived. Its main objective is to facilitate portability of data across multi-platform systems. In 2000 XML gave rise to XHTML, a reformulation of HTML aimed at adressing limits in the latter's original specification.

Readmore...

CMT3315 Intro - XML, What it is and where it came from

Given the summer recess, it has been a while since my last post but it's time to pull the proverbial socks up and get back to work.  During this semester, the blog will be focusing mostly on the eXtensible Markup Language - XML for short - and there's a lot to cover, so let's get right to it:

First Things First

So what is XML? Before answering that question one must understand where XML comes from and more importantly its purpose.  To do that we need to take a look at the early days of computing, back in the 1960's, where the idea of storing documents in computers in such a way as to make them "understandible" to software, was still fresh in the minds of researchers.

GML
Charles Goldfarb, Edward Mosher and Raymond Lorie, three researchers working for IBM came up with GML, a set of macros that implemented mark-up tags to describe the logical structure of a document.  Interestingly, GML is known today as "Generalized Markup Language" but originally the acronym stood for the researcher's surnames! 

SGML

GML was eventually extended by Goldfarb in the mid 80s into the Standard Generalized Markup Language (SGML).  SGML was designed to make it possible for large entities (such as government) to share machine-readable electronic documents.  The main idea was to embed a set of tags within a document which a software package could use to derive information about that document.  For this to work, the set of tags had to be standardised, made publicly available and most importantly be platform independent.  SGML is a very large and complex markup language, suitable for storing equally large and complex documents but rather cumbersome for use with smaller, simpler documents.  The beauty of SGML however is that it can be used to derive smaller, simpler mark-up languages better suited for smaller documents.  Such languages include HTML (Hyper-Text Markup Language) and of course XML.

XML
Going back to the original question: "What is XML?", XML is an extensible markup language used to encode documents in such a way as to make the knowledge structure of a document known to a software package.  It separates the actual content of a document from it's structure and presentation.  Being a subset of SGML it is much simpler to use and is ideally suited to store, and more importantly transport, electronic documents.  It's most common use today is to transmit data between applications, irrespective of the platform.  The beauty of XML is that you define your own tags which means that any document structure can be described in XML.

XML became a W3C Recommendation on February 10, 1998 (w3schools.com) and the first web browser to support XML was Microsoft's Internet Explorer 4.0.

Next time, I will be comparing XML to HTML.  In the mean time, have a look at this post from my blog for more on XML.

Readmore...

Up in the Cloud

Surely, one of the most popular buzz words since Web 2.0 has to be "Cloud Computing".  The trouble is that there are many different schools of thought on what the Cloud is or should be.  "Platform as a Service", "Software as a Service", "on-demand computing" and "Internet as a platform" are just some of the phrases used to define cloud computing.  However you wish to call it, to me Cloud Computing is about history repeating itself, the next phase of a cycle.  We're shifting software and data back from our desktop PCs to remote systems known collectively as "The Cloud"

Think about it, back in the beginning of computing, software ran on mainframes and super (for the time) computers and accessed through dumb terminals (thin clients) in a hub and spoke fashion.  Fast forward a couple of decades and the personal computer is introduced, full of promise that software could now be installed on client machines.  This eventually led to the client-server model, where fat-clients running software locally accessed data residing on central servers. Today, the focus is shifting away from the client back to the server which is now provided as a service and resides on the cloud.  This does not mean that our clients are becoming thin again, quite the opposite - today's smart phones for instance really pack a punch hardware wise - however the applications themselves are being offered over the internet with no local installation necessary.

What's Great about The Cloud 

For starters you don't need to worry about software installations, compatibility/ and updates. Cloud applications are offered as a service and accessed through the browser without the need for local installation.  Another perk is the ability to be able to access your data and apps from anywhere, using any workstation. Since all your data and apps reside on the cloud, they can be accessed from anywhere greatly increasing your mobility. 

Scalability is also another plus point.  Businesses can request more processing power or storage on demand as required but can also scale back down again during off-peak/slow business periods, freeing up resources and lowering costs because you generally only pay what you use.  So the scalability offered by the cloud is also very flexible.

Cost considerations are somewhat a double edged sword but what's certain is that if you opt for the cloud, your initial set-up costs are dramatically reduced.  You will not be incuring costs for acquiring servers and no servers means no data centres with their high electricity bills.  Maintenance and operational costs are also considerably reduced.

Your business can also focus more on strategic objectives because there is much less time spent on deployment, maintenance and operations.

So, What's not to Love

The biggest issues with cloud computing relate to service reliability/accessibility, security and privacy, or at least how they are perceived with respect to the cloud.  Businesses that have their own data centres and have been sitting on their data since starting up will find it very hard to accept that moving that data to a 3'rd party's data centre might be the better option.  The perceived loss of control in most cases overshadows the benefits gained by moving to the cloud. 

Unfortunately, some of these concerns are well founded.  How reliable is the service being provided?  What kind of impact would temporary service unavailability have on your business?  Can a business make sure that it can completely delete any of its data?  What degree of control does the service provide?  What happens to your data if you decide to switch providers?  These questions are generally hard to answer.  Although the idea behind cloud computing is fairly old, its implementation was not possible until very recently and legislation in respect of cloud computing is generally weak.  To complicate things further, your data could be stored in different countries and different countries have different laws.  There is still a way to go as far as legislation is concerned until we can start answering these questions properly

Looking ahead

Legislation and perceptions notwithstanding, cloud computing is flourishing and seems to be the way forward.  Office apllications such as Google Docs and Microsoft Office 365 are good examples of successful cloud services.  CRMSs, online storage systems (Skydrive, DropBox etc) and other applications such as photo editing packages are all being offered as cloud services.

The real challenge will be the culture change required for businesses to shift their operations to the cloud.

Readmore...

Social What?

Social Networks have been around since before the internet itself.  Ever since computers could connect to each other, so did the users at each end.  The social networking heavyweights of today such as Facebook, Twitter and Google+ are just latest products of a long (and vicious) evolution of the genre.  I’ve always had this sort of love-hate relationship with social media and as the products evolve so too are my feelings evolving into a love-to-hate attitude.

The Evolution of the Social Network

The roots of social media can be traced back to the late 70’s with the birth of the Usenet system which let users read and post messages/articles to one or more categories (newsgroups), similar to modern-day forums.  Usenet systems sparked the development of newsreader clients which are themselves the precursors of today’s RSS feed readers.

Shortly after Usenet, the first Bulletin Board Systems (BBSs) started coming online which were initially hosted on personal computers.  Users could dial-in on the computer’s modem to gain access to the BBS and could leave messages or upload files on the host computer.  A major drawback of these systems was the fact that the number of concurrent users accessing the BBS was limited by the number of phone lines available.  This generally meant that only one user at a time could access the BBS.

Next came online services and Instant Messaging.  The pioneer of instant messaging was the (initially) UNIX-based Internet Relay Chat (IRC), developed in 1988.  Users could send messages and share files through IRC in real time, something which was not possible on BBSs.  IRC also introduced the idea of chat ‘channels’ and private-messaging and is still somewhat in use today.  Although IRC clients are now available for most platforms, the first instant messaging programs for PCs was ICQ which proved extremely popular when first released.  SPAM and privacy issues however all but killed it off in the US and Western Europe, but despite its shortcomings, it remains popular in Eastern Europe and Russia.

Some consider dating sites as the birth of social networks but the first real modern-day social network was Six Degrees, launched in 1997.  Unlike its contemporaries, Six Degrees allowed its users to create comprehensive profiles and add people as friends - essential features of a modern social network.   There were/are numerous others: LiveJournal, Hi 5, LinkedIn, MySpace and of course FaceBook and Twitter.  Google is also running beta tests of Google+, which promises to be the next big thing in social networking.

Why so many? From the outset it was apparent that social media was a powerful thing, but social media projects are also some of the most volatile out there.  Six Degrees was launched in 1997 and  perished in 2001, but went out of fashion even before that.  In just 4 years, it went from launch to shut-down, such is the vicious nature of the social media phenomenon.  Sites like Hi 5 and MySpace also lost most of their popularity.  Why?  Users are quick to switch from one system to the next just to gain that extra feature or keep with the latest trends.  Loyalty means next to nothing in this environment, it's all about trends and the next big thing.  Failure to stay ahead of the game (and keep users interested) spells the loss of your user-base in a matter of months if not weeks.  

My Perspective

There's no denying Social Networks are great but I'm hardly what you could call a fan of the things.  I don't have a facebook or twitter account and I only have a Google+ account because Google created it for me!  Funny thing is it's hard for me to explain why I'm not inclined to have such accounts.  It's got nothing to do with age, profession or social standing - social networks are made up of people from all walks of life.  I guess privacy issues are a part of the problem.  Personally, I never feel the need to share a photograph of myself with the rest of the world - no matter how 'private' a system portrays itself to be - but that is still something I can control, it's my choice.  What gets me is the fact that you may feature in someone else's photograph, even in the background, someone recognizes you and suddenly you're tagged - which is something you have no control over.  It's also hard to be sure who's on the other side unless of course chatting live using a web cam.    

I'm also perplexed at how people can be so reserved in person but all inhibitions are out the window the minute they're on-line. This behavior begs another question.  Why do we find it so easy (and feel so uninhibited) in sharing personal information on the net but then find it so hard to open up to people (in person) and build relationships?

Another issue that bothers me is the fact that these systems tend to become addictive.  I have plenty of friends that cannot go an hour without checking their accounts let alone a day.  I vividly remember an episode which at the time made me laugh:  I was giving a course on web design to a class of teenage students some time ago.  Come lunch time of the first day I simply said "You may go outside and have your lunch now" and the whole class instantly loaded up their browsers and logged onto Facebook.  Some of them took out their lunch and to eat and when I pointed out that no food or drink was allowed in the lab, most of them just put their lunches back in their bags!   This happened for the rest of the one-week course.  Most of the class never bothered to eat.

It's not all bad however.  Social networks are a great way of keeping in touch with distant loved ones for example or long lost friends.  There is no denying that they take communication to a whole other level.  But at what cost?  Maybe I'm being paranoid but aren't these companies in a position to build complete profiles of their user base, habits, likes, dislikes, personal histories... personalities even?  Given today's powerful data analysis methods it's not hard to imagine how these companies can exploit this data - which we are all too happy to supply - to their advantage.  Personally, I find that invasive and too high a price for the sake of keeping in touch.

Conclusion

I guess it's just me against the world :)

Readmore...

Mobile Devices and Geolocation

The topic of mobile phone development is a minefield of myths, false truths and misconceptions. In this post I will try to clear things up a bit as much as I can and also take a look at how to exploit geolocation from our mobile devices.

The Mobile Web

One of the most common misconceptions I come across is that there is no need for a website to adapt to a mobile device. The reasoning behind this idea is the fact that the internet is platform independent and that the browser should do the dirty work. When faced with such an argument I tend to respond with another: “If the website will not adapt to a mobile device, can that mobile device adapt to your website?” The typical response I get is: “Sure, why not? You might need to scroll a bit more but it looks fine.” Let’s set the screen resolution topic aside for a moment and consider the following example: Let’s say your website uses cascading menus which open up when the user hovers over them with the mouse. Let’s also say that we are going to browse the website using something like an iphone or similar multi-touch smartphone. Will that menu work? Can you “hover” over the menu using a touch screen? Not to my knowledge, so one of your more important features on your homepage is lost on a mobile device. And this is not some mobile phone from the late 90’s we’re talking about, but a latest-generation smartphone running a proper HTML browser. It’s not that the phone is not willing to adapt to the site, it simply can’t.

Screen resolution is another factor. I remember back at the beginning of my career as a developer (late 90’s) we had desktop machines that boasted an 800x600 screen resolution (1024x768 if you were lucky) while our end users only managed 640x480. It was company policy however that all the software we produced had to target 640x480, irrespective of what resolutions we were able to push. Today, the sheer variety of devices out there pushing all sorts of different resolutions is quite staggering and scary at the same time, but makes it even more important for developers to be aware of screen real estate and its effect on user experience.

Another myth I sometimes hear is that people are not using their mobile phones to browse the web. This might be true of people using ‘classic’ phones but it would be naïve (or rather stupid) to think that smartphone users (which are on the rise) aren’t. We as end-users still want to use the same websites we use on our desktop machines on our mobile devices, it’s the way we use them that’s different.

These are just a few considerations on why developing for mobile phones/devices should be treated differently. For a product to be successful, developers must be aware of the platform they are targeting, and let’s face it…

It’s a Jungle Out There

As mentioned earlier, the sheer variety of mobile devices available today is staggering and their capabilities are equally varied. The evolution of the mobile phone in particular is quite remarkable. The mobile phone started out as being just that, a phone which you could carry around and use anywhere you liked. We then had low-end mobile devices with very basic web support and limited memory. At this stage a mobile phone stopped being just a mobile phone and became a device. These were followed by devices that supported HTML and Java applications. Today’s smartphones are literally hand-held PC’s running fully fledged OS’s – my Android “phone” has a 1Ghz processor, half a gigabyte of RAM and 8Gb internal storage. I use it to browse the internet, check my email, run office apps and sometimes, even phone people up . The number of people using such devices is constantly on the rise and so the landscape of web development is rapidly changing. In some cases, mobile device browsers are better at handling cutting-edge HTML5 and CSS 3 features than their desktop counterparts for instance. Try http://www.html5test.com from your favorite desktop and mobile browsers, you might be surprised at the results!

If a web product is to be successful in this varied landscape, it is vital that the developers understand the targeted devices, not just at a software level, but even at the hardware level. What does the device support? What does it allow it’s users to do and how? I recently came across this article by Dan McKenzie that deals with how to go about designing for Android which is currently the most popular smartphone platform out there. Quite an interesting read.

We’ve seen some of the “limitations” brought by mobile devices, such as smaller screen real estate and no “hover” but it would be wrong to think that it’s all bad news. Mobile devices also bring to the table interesting and powerful features which are missing from their desktop counterparts. One of these features is geolocation.

Geolocation

Geolocation is one of those features that brings with it a whole range of possibilities for our web applications. Location-based services, geo-marketing, geo-tagging, geo-targeting and web analytics are just a few examples. Gelocation adds meaning to global positioning where rather than just a simple set of co-ordinates, your position is described in terms of street name and how far you are from the closest restaurant!

Your device can determine its position in various ways including GPS and, WiFi positioning and even through Cell information of your mobile phone network. One way of making use of this information is through the W3C Geolocation API, an effort by the W3C to standardize the way a mobile device retrieves positioning information.

So, how do we use this API? The first thing we need to determine is whether our browser supports it by querying the “navigator.geolocation” object:

If (navigator.geolocation==undefined) {
   alert (“Your browser does not support Geolocation API”);
}

If the API is supported we can go ahead get our current location by calling the “getCurrentPosition” function. This is an asynchronous call which receives two callbacks, one for handling the returned position and another to handle any errors. You can also (optionally) specify additional properties to improve accuracy for instance. Here’s an example:

function pageLoaded(){ //this function is called from the body's onload event
   
   if(navigator.geolocation==undefined){
      document.getElementById("MSG").innerText = 'Geolocation is not supported';
   } else {
      document.getElementById("MSG").innerText = 'Geolocation is supported';            
      navigator.geolocation.getCurrentPosition(userLocated, locationError)
   }
} 

function userLocated(position)
{
   var lat = position.coords.latitude;
   var lon = position.coords.longitude;
   var alt = position.coords.altitude;
   var tim = position.timestamp;

   // display the returned values on the page     
   document.getElementById("LAT").innerText = lat;
   document.getElementById("LON").innerText = lon;
   document.getElementById("ALT").innerText = alt
}
 
function locationError(error){
   //handle error;
}

We can also use the W3C Geolocation API to track the device’s location. By tracking the location we can also determine other factors such as speed, distance and direction of movement which can be used by our application. Here’s an example:

var watchID = false;
function toggleTracking(){
    
   if (watchID==false){
      watchID = navigator.geolocation.watchPosition(userLocated, locationError);
      document.getElementById("btn_trk").value = "Stop Tracking";
   } else {
      navigator.geolocation.clearWatch(watchID);
      watchID = false;
      document.getElementById("btn_trk").value = "Start Tracking";
   }
}

To track the device's position, a call is made to the "watchPosition" method of the geolocation object which accepts two callback functions just like the "getCurrentPosition" method. "watchPosition" also returns an handler to the watch (watchId) which is used later to stop tracking by calling the "clearWatch" method.

I must confess that I had trouble testing the tracking function, especially while on foot. I tried creating a function that calculated the distance being travelled as well as the direction but could not test it very well as the response time was jerky at best. I admit that walking up and down the corridor of my house might be too small a distance for proper testing but it was the best I could do since I was editing javascript on my laptop and copying files to and from my mobile phone. I did register some position changes at times but it was sporadic and not enough to draw any conclusions. I have however installed a code editor on my mobile phone such that I can edit the code on the go. The plan is to test the code while travelling to work to see if I can get more encouraging results. I’ll also play around with the A-GPS settings to see what effect they have on accuracy. I’ll let you know how it goes.

Readmore...