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.