There are many ways of being inconsistent. They will all tend to hurt your users in different ways.
Inconsistent naming will make it hard to remember which is what, and will cause subtle bugs
when processing software looks for the wrong information. This is one of the simplest to get
right and yet is often wrong as the result of things being specified on the fly and not
revisited later. The typical example is SVG having
ellipse, etc. but
rect instead of
rectangle. It does
make a language harder to learn.
Incoherent features are harder to spot because they tend to happen when people use your ideas in unexpected ways.
A good example is the different treatment applied to shapes and animations in SVG. The
following will work and display a second rectangle inside the
<svg ... <defs> <rect ...="" id="dahut"></rect> </defs> <g> <rect x="10" y="42" ...=""></rect> <use xlink:href="#dahut"></use> </g> </svg>
But the following, while valid, will not cause the
g element to be animated:
<svg ... <defs> <animatetransform ...="" id="dahut-anim"></animatetransform>< /defs> <g> <rect x="10" y="42" ...=""></rect> <use xlink:href="#dahut-anim"></use> </g> </svg>
defs will be animated, which will do nothing. This sort of
discrepancy confuses authors, many of whom will try the latter at some point. There is no
silver bullet to get rid of such issues; the best you can do is that, whenever you add a
new construct to your vernacular, either constrain it to places where you can ascertain its
behaviour, or, if it is meant to be used in arbitrary locations try to go through the
entire rest of your language and to imagine how it would interact with each construct.
Note that while this is most easily exemplified with behavioural features, it applies just as well to semantic ones. The many ways in which one can create bogus, meaningless data will often boggle the developer’s mind.
↖︎ Back to list