Sorry for my ignorance, but wouldn't schematron be more appropriate for no 4.? <div><br></div><div>Laurent<br><br><div class="gmail_quote">On Thu, Mar 8, 2012 at 4:06 PM, Roland, Perry (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, everyone,<br>
<br>
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. :-)<br>
<br>
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 ...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
What are the options for software?<br>
<br>
1. Silently ignore anything it doesn't understand.<br>
2. Ignore anything it doesn't understand, but alert the user to its "deafness".<br>
3. Refuse to work with anything it doesn't understand.<br>
<br>
All of these options conform with the notion of "supporting MEI".<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, I want to<br>
<br>
1. leave the current crop of attributes in place (no deprecation, but *explanation* of their proper uses),<br>
2. add @ornam with appropriate values,<br>
3. devise methods of converting between attribute- and element-centered markup,<br>
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.<br>
<br>
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. :-)<br>
<br>
--<br>
p.<br>
<div class="im HOEnZb"><br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</div></div></blockquote></div><br></div>