Re: [xml-dev] Seduced by Markup

[Michael Kay <mike@saxonica.com>]

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.

Michael Kay
Saxonica


On 19 Nov 2013, at 22:27, cbullard@hiwaay.net wrote:

> Sean asks why no one reads the notation:
> 
> 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.
> 
> len
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php