[MEI-L] trills within beams

[Laurent Pugin]

Sorry for my ignorance, but wouldn't schematron be more appropriate for no
4.?

Laurent

On Thu, Mar 8, 2012 at 4:06 PM, Roland, Perry (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:

> 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
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120311/502e3065/attachment.html>