[MEI-L] Antw.: trills within beams

[Benjamin W. Bohl]

Hi LISTeners,
hi Perry!
What you wrote about the trill question on second thought is exactly what kept nagging in my mind having followed the discussion for the last few days. As I always understood MEI was/is being designed by scientists for scientists in order to being able to capture music phenomena that one was not able to in "common" notation software, at least because its development was not bound to that of a certain software. Moreover there was no big notion of replacing/taking the position of a interchange-format for different software. Considering this it is VERY important to listen to the needs of hand encoders and keep in mind that straight forward encoding possibilities are features that capture attention of future editors and users of MEI; of course that's what sophisticated software might accomplish as well. But to the day there is no such thing for MEI-all or ans other subset thereof. Of course the needs of software developers is equally important because we want them to make real that sophisticated thing.
Perry, I greatly appreciate you "stepping back" and looking on what's happening from a greater distance. You proposal sounds to me like a sound plan.

Best wishes,
Benjamin

----- Reply message -----
Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>
An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
Betreff: [MEI-L] trills within beams
Datum: Do., Mär. 8, 2012 17:06


Hi, everyone,

You know, I was almost persuaded by the deprecation argument.  But, thinking more about Kristina's original question and Eleanor and Andrew's responses, I think that's not the best way to go.  My first response to Kristina was written in a moment of weakness and Eleanor was correct to call me on it.  :-)

As I've said many times, I sympathize with developers who want "the one, true, correct way".  But, that can lead one down a rocky road.  For example, you know that place where ships are docked?  What's the word for that in English?  Is the "one, true, correct" word "harbor" (as we spell it in America) or is it "harbour" (as it is spelled/spelt by our British cousins)?  Then there are the Old and Middle English spellings.  Of course, all are correct in the appropriate context.  Writing a word processor that checks spelling would be a lot easier if there were one "right" answer, but ...

MEI is designed for multiple contexts.  What is true and correct for one use or user, may not be for another.  For example, MEI supports printing but it is not designed exclusively for that purpose.  I think the practical result of this philosophical approach is that each use / user must define the context in which it / he operates.  This means making choices.

Kristina identified a need for a trill attribute in the context of hand encoding (or one-pass encoding, as much as that's possible in MEI), which was seconded by Eleanor and Andrew.  MEI already provides attributes that function similarly, so the question, "Why can't I ...?", was legitimate.  Surely, the answer is not to define the question out of existence.

When I said before that I could imagine a future in which these attributes didn't exist, I was thinking of the time when sophisticated MEI authoring tools exist.  And that time may come someday soon, but it's not here yet.  And even if no one authored or edited MEI in oXygen, there would still be the analytical uses to consider -- see below.

In spite of my temporary lapse, I still believe the appropriate answer is to accommodate these multiple contexts.  Software, of course, then must also be able to deal with multiple contexts, probably by switching between them rather than supporting them all simultaneously.  (In the word processor example, one switches contexts between British and American spelling by selecting different dictionaries.)

What are the options for software?

1. Silently ignore anything it doesn't understand.
2. Ignore anything it doesn't understand, but alert the user to its "deafness".
3. Refuse to work with anything it doesn't understand.

All of these options conform with the notion of "supporting MEI".

Anything less, such as deprecating one context or another in MEI itself, isn't acceptable.  I think that if we deprecated @tie, @slur, etc. it wouldn't be long before the cry went out to add them back.  Or worse yet, individuals would start extending the schema *each in their own way* to get them back because they are useful in both simple input systems (that is, using an XML editor) and in the analytical context where one often needs to tightly couple an entity (in this, a note) and its properties for ease of conceptualization and for efficiency (it takes resources -- time and memory -- to navigate down into the document to find a trill that might be associated with a given note).

In order to avoid putting them back later or virtually assuring uncontrolled extension, I believe it's better to allow these attributes (and even add more; that is, @ornam or similar, in this case).  Doing so steers modifications toward restrictions, which are easier to create, maintain, and enforce.

I believe this places MEI in the same philosophical space as TEI.  That is, one should not use TEI straight out-of-the-box without making some choices. The mei-all schema (like tei-all) is only the first step in defining any particular use of MEI.

So, I want to

1. leave the current crop of attributes in place (no deprecation, but *explanation* of their proper uses), 
2. add @ornam with appropriate values,
3. devise methods of converting between attribute- and element-centered markup,
4. create customizations of mei-all that make it easier for users/agents to declare what they're ready to accept and conversely what they will ignore / refuse, for example, a customization that emphasizes attributes and one that emphasizes elements.

This plan is not new.  With the addition of no. 2, it's what I think we've been working toward for quite some time.  We just momentarily stepped off the path.  :-)

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120309/e0d1db7a/attachment.html>