Cart
[Home] [By Thread] [By Date] [Recent Entries]
While I think that "less is more" applies to markup definition languages - I'll take Examplotron over XML Schema any day - I'm not at all convinced that it applies to the languages we create with markup. The problems you describe here and the dreams of fixing them are the natural result of trying to create one markup vocabulary that addresses all the concerns of a community. We dream of a simplicity that doesn't exist. We blame the subject matter experts and markup engineers for not getting it quite right. Then we curse the additions and removals as we iterate, hoping to cover the same ground properly. The problem is simpler, though - we don't share the ground. We all see the information described by a vocabulary differently. Even situations that seem simple often reveal far more detail than their explorers thought possible. Markup has value. You won't find that value, however, by trying to simultaneously address all needed possibilities and yet retain that key virtue of simplicity. Thanks, Simon On 12/19/13 7:56 AM, Costello, Roger L. wrote: Over the last 15 years XML languages (vocabularies) have come and gone. Some were good, some were bad. Some endured, some perished. So what makes a good, enduring XML language? Here are some thoughts. I welcome your additions to this list. 1. A good XML language is created in a finite amount of time by a finite group of people. Conversely, the development of bad XML languages just seems to go on forever. I heard of one language that started development back in 2000 and now is on version 10. Advice on what should go into that language is coming from a seemingly infinite number of different people. The first version was good; subsequent versions have steadily gotten worse. I think a reasonable guideline is to set a one year deadline for the development of an XML language. Declare victory with whatever you've created after that one year. And keep the development group small. No more than, say, a dozen people. Be sure the group contains a good mix of Subject Matter Experts (SMEs) and technology experts. After one year, stop work. There are no versions 2, 3, etc. 2. Create the simplest possible XML language. No bells or whistles. 3. After you announce your XML language to the community, you can't take it back and simplify it. The community won't accept a removal of capabilities (even if those capabilities are bogus). It is too late. If, after releasing it, you glumly realize that your language is too complex (and the community is not adopting it), well, accept your losses and hopefully learn a lesson. /Roger -- Simon St.Laurent http://simonstl.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
