Not long ago I had an interesting conversation with a young man who had just written his first XML document-processing application (of course, he wrote his own document vocabulary). He then showed it to some of the senior people in the organization where he works, and was shocked and disappointed at the responses he got. He had clearly done a lot of reading, worked hard, and build something to impress the powers that be. He wanted recognition, praise, and perhaps additional responsibilities. They laughed at him.
He is the son of a friend of a friend, so he felt safe asking me what had gone wrong. The first thing I told him is that the big thing he had done right was to dive in and learn about something he found interesting but knew nothing about. I thought that was laudable, and that spirit would serve him well in the future.
Now, let’s look at some of the problems with his XML vocabulary. He said that they laughed at him because:
What it Looks Like: “They told me it was bad XML because there are tags for what things look like and what I want the app to do as well as some for what the stuff means. They said good XML is about meaning, not about look and feel and that, when tagging regular documents, the formatting should be separate from the content.”
Types of Markup: “They talked about generic markup and structural markup and containers and procedural markup (which they said was ‘deprecated’ - a word I did not know but that sounds pretty snooty to me).”
Mixed Metaphors: “They told me I should not write my own vocabulary until I had made sure one of the ‘standard’ ones would not work for me. Hey, I started with DocBook, but my project is really special, and DocBook did not define all I needed. Then my librarian friend told me that the reference model in JATS is better than the one in DocBook, so I copied it in. Why can’t I do that?”
Natural/Intuitive Tagging: “I also made my language a lot more natural by using tags from HTML whenever I could. You know, so people would know what the tags meant.”
And he said: “I read the XML recommendation”:
“I didn’t see anything in the XML recommendation that says anything about avoiding look and feel, and besides, XSL-FO documents are XML and they are all about what the page should look like.”
“And the XML recommendation never mentioned: procedural markup, descriptive markup, generic markup, or structural markup. If this stuff is so important to making good XML why doesn’t the XML specification talk about it?”
“If it’s not in the rec, how is a person supposed to know it’s important and how do I learn about it?”