They do. The notation is hard not in basic understanding but in
practical use because:
1. It is layered. There are at least three languages on top of each
other all devised at different periods of history and unfortunately in
now uncommon dialects (most of us really don't speak Italian).
2. Reading it has to be accompanied by deep physical training. The
problem of the multiple accidentals is fingering. It's relatively
easy to master the hand to eye of the patterns on all the white keys.
Then as each sharp or flat is added, those patterns are altered a
little in space.
3. It is interpreted. What does a poco a poco really mean in real time?
4. Mistakes are often punished by whacking. Some music teachers are
dears. Others are pedantic bastards. YMMV but...
5. Like any language, the later you start, the harder it is to learn.
I can write music easily. I read it very badly. I have an
uncommonly good ear but a badly trained eye.
6. The physical aspects vary by instrument. If you are as I am, sort
of a multi-instrumentalist, the reality of keeping up multiple
fingering techniques much less armatures, breathing technique and so
on is ... daunting. I treat these in a just-in-time way, meaning I
brush up a few days before recording and lose the skills to some
percentage in the periods between using them.
The deal with parameter entities isn't that the % makes a bit of
difference. That's trivial. The eye spots it. Same as a b or # in
music. When there are lots of them, it isn't hard to know what they
mean; it is hard to put the finger on the right note without practice.
The trick is the named strings aren't really objects as some pretend
or properties. They are patterns that emerge from having tagged a
document and given it names or invented them out of whole cloth. They
mean that the document structure was a priori basic and easy to build
but there may be lots of names in lots of orders. However given a
very large set of structures, one has to scan back and forth in the
DTD or Schema to determine what is an isn't valid. Drop the
inclination to alphabetize those and it gets very hairy very fast.
The parameter names may not be meaningful. Say %text; then an
exception is found that occurs infrequently so %text2. The amount of
parameterization may be arbitrary, you're stuck with what the DTD
designer thought was important or when they got tired and quit making
them. They aren't likely in the order you need them for scanning to
interpret the structure. Worse they impose an "imperious necessity",
the conviction that unless you use them in design or practice, you
aren't really a "professional" and may be whacked.
IOW, they sacrifice local context for a global context and introduce a
lot of cognitive overhead. Same for having one instrument's notation
rule all composition. Thank Engineers for transpose functions and
midi. Loves the tools, I do. ;)
A parameter entity mainly benefits the schema maintainer and only
weakly helps the user of the document who finds they rely on the
tools. It isn't a big deal until one needs to build not a document
but a secondary artifact such as a transform or a style sheet.
Templates are also affected but templates are yet another artifact or
"theory" about the document. They impose yet another point of view
about what the most common patterns are. I'll provide them if my
customer really needs them and most do because they fear the
schema/DTD, can't read it and think tagging is actually a
differentiable skill set.
I'll say it again: education and experience are the real problems of
XML. I cannot describe the issues of recent gigs where I go in and
the person they tell me is in charge, has written the requirements,
has even taught courses in XML and adjunct subjects is a ... tagger.
Full stop. My employer (or pimp as some say) asked me how to
determine the actual level of skill people who applied as contract
hires. I gave her ten shibboleths and the correct answers. I told
her to ask these question and if they cannot give her the correct
answers, not to send them to data design gigs no matter how much
tagging experience they have.
Reading notation and performing are not composition. That is
interpretation with practice. A tagger doesn't need to read parameter
entities. A designer does.
It's stuff one has to learn and keep learning. Jacques Brel steals
from Lizst and uses some jazz accidentals. The first is historically
interesting but not that useful. The second is vital to stealing from
Brel. If it increases the range of expression, then we endure the pain.
