Michael Kay says: "I would say that reading a DTD is rather like
reading a musical score that doesn't say "pp", "mp", "mf", and "mf" to
indicate dynamics, but instead says %volume17, and you have to scan
100 pages of manuscript to find the definition that tells you that in
this particular score, %volume17 means "mf". Or it might not be in
that manuscript at all, but in another one that's cross-referenced in
a footnote."
Precisely. Although "refs" are marginally better. :) For some
tasks, direct access is required.
In this example, if they say pp, I know it means "less volume than not
much volume" but this is where the notation favors expression and
adaptation: it isn't precise enough to tell the midi system unless
there is another map to an instruction to the sound engine. In a good
editor (say Sibelius), you can find that map and set those values per
composition or as defaults for your individual "style".
In the case of a poco a poco (little by little), I would have to set a
scaling value OR observe the director's hands and listen to the people
around me.
The first case is relevant to the notation complexity reference I
noted. What is the cognitive cost for using a given notation in a
given situation?
The last case is interesting and relevant to the cognitive computing
model where neuronal pathways and white matter columns "learn" by
"experience" and "activate" given sensor inputs and a spike train. (I
do wonder what XML brings to cognitive computing.)
The two qualities I think important to the XML professional of some
given skill level or depth of understanding are expressibility and
adaptability.
1. Tools may be inapplicable. It's ok to use the capo and just
"shred". Don't apply to a jazz gig where capos are death. You are
playing a bit out of tune and volume can't be used to cover tuning or
lack of chops given a bm7-5 (more accidentals make tuning more
critical because overtones matter). You know everything about HTML5
but you've just been told to style for PDF and your schemas were
designed with XSLT in mind and you are only allowed to use the local
tools so old school it is. Get to it.
2. The piece makes a difference. A guitar is great for big fat
chords. OTOH, did you learn scales as a box model (in position) or on
single strings? You can try to play Jerry Reed or even the Stones in
a standard tuning but they never quite work because these guys aren't
guitar players, they are as Reed said, "guitar thinkers". They retune
the guitar to make the chords easier to play or even possible. You'll
never play Jerry Reed without discovering how he tuned the guitar
(watch some YouTube vids and look at his left hand). BTW, a lot of
Joni Mitchell and David Crosby are the same: open tunings. Say
chord clusters aka, why can't good musicians figure out the first
chord in Hard Day's Night without a mathematical analysis?
Messages are one level of complexity. Documents are a different level
of complexity. Notation complexity should be appropriate to type and
task. User must be trained and practiced to do both or learn both
fast. Fundamentals matter and I say that as someone who has failed in
that regard because I am a musician first and only a computer
professional by necessity. So I crab walked my way into this field.
(Cred? My sweet aunt Martha. Sheesh. I got into the business when
atoms were as big as houses.)
3. Tools fail. If you lose a string in the middle of a song live,
can you cover? If your XML editor fails because of dialog freezes,
can you open the file editor and keep going?
If you can't read a DTD or XSD or RNG and that is required, be
prepared to learn fast. The more of the XML fundamentals you
understand, the better prepared you are. Practice scales. Just
shredding won't cut it. On the other hand, playing only scales sound
terrible so shred often. Let your eyes and hand be able to just do it
without too much though when doing it but don't let you eyes and hands
add viscosity when the brain needs to acquire new means of expression.
Tools should amplify and exemplify, not classify.
