OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Guidelines for the development of an XML language (vocabulary)

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.


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.


Simon St.Laurent

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS