Come On India - Dikha do !!

India's strong rupee

... these are new sets of challenges before us, now that we 'exporters' are facing an uphill task to complete, it is important to note that 'cheap' is out and need for 'quality' is in, some years back I read a writeup where the writer stressed the need for correction in our 'Incredible India' campaign from 'cheap' to 'cost-effective' and our associated mind-sets.

... now that we are trusted for our services, we need to be innovative and create value added services, and more importantly, we need to come up with more 'products' in place... to truly become a power to reckon with...

... and I truly second the writer when he says - '... an enviable problem to solve'

Opinion: Is it a disease or a symptom ?

... referring to this article, I have mixed reactions to share... may be I truly understand the concerns of NASSCOM when they rubbish the health minister's views towards the unhealthy work culture at IT/ITES work place, fearing increased government control or may be this can potentially scare away the investors or may be this can give voice to feelings of those who go through the grind everyday or may be we are not too sure of the real intent of the minister.... what if he is really concerned about the state of affair ? what if he is pointing towards a symptom of a bigger problem ahead...

frankly speaking, i strongly believe that government must work like an operating system, that runs the 'system' while hiding most of the underlying complexities... and based on the 'user-settings' can take control quartine it or point to a potential problem to enable 'user' to take an informed decision.


I would not like to start the usual 'yada-yada' of he great Indian Heritage of disciplined life... but isn't it high time we truly take note of minister's statement and try bringing some discipline in our lives... Cheers for a healthy India :)

XML: Cornucopia

... well you see, I discussed in one of my previous post that certifications play an important role in giving structure to your study, they establish a common minimum program to be covered... little did I know that when one is going to study XML it can get tough even though you have an agenda in place. In the absence of any one-stop-key-to-success-guide books available in the market, it is difficult. I could now feel what exactly the phrase 'xml-hell' would mean for people who swear by it :))

The verbosity of XML content has it's own woes... there seems to 'too-much' of information available everywhere... Call it my XML cornucopia ... one neat resource for study...

XML: Design and Architecture

http://www.ibm.com/developerworks/xml/library/x-eleatt.html

When to use elements versus attributes ?

Any one who has worked with XML will very well know how difficult it becomes to answer this question and in the absence of any clear guidelines the whole information modelling exercise may get wrong. The above article provides a head start towards that end.

In some cases the answer is pretty unambiguous:

• If the information in question could be itself marked up with elements, put it in an element.
• If the information is suitable for attribute form, but could end up as multiple attributes of the same name on the same element, use child elements instead.
• If the information is required to be in a standard DTD-like attribute type such as ID, IDREF, or ENTITY, use an attribute.
• If the information should not be normalized for white space, use elements. (XML processors normalize attributes in ways that can change the raw text of the attribute value.)

For the grey areas the tips are:

• Principle of 'Core Content': Data goes to elements and meta-data goes to attributes. Simply put the data elements which form part of 'your' solution domain are element, while those 'qualify' or provide more details about the core content goes to attribute.
• Principle of Structured Information: If the information is 'extensible' make it an element, while 'atomic' tokens goes to attributes.
• Principle of Readability: If the information is to be understood by the human readers make it an element, else create an attribute. As the writer puts it '...information tokens that are not natural language go in attributes.'
• Principle of element/attribute binding:Use an element if you need its value to be modified by another attribute. XML establishes a very strong conceptual bond between an attribute and the element in which it appears. An attribute provides some property or modification of that particular element. Processing tools for XML tend to follow this concept and it is almost always a terrible idea to have one attribute modify another.
  

XML: Start here

http://www-03.ibm.com/certify/tests/edu142.shtml

The good thing about certifications is that they provide a well-defined structure. This is important to set SMART goals for oneself.

Long way to go before I sleep...

XML: The certification path

Web 2.0, Semantic Web, Service Oriented Architecture, Model Drive Architecture, Code Generation... the list looks fantastic and are sure the buzz words today. In an attempt to understand the concepts, one really needs to be adventurous, start at edges and an inter-disciplinary approach is required.

In order to tame them I have my set of tools with me, while I'm fairly comfortable with Java, I do not have much undersanding of XML concepts. I wish to fill the gap by learning XML...