[MEI-L] list-related changes

Wed Nov 11 23:36:02 CET 2015

Raff,

I understand TEI’s method, but I don’t think it’s feasible in MEI.  Musical elements are frequently adjusted in terms of typography and location individually, making it very difficult to use a class-based methodology (even an ad hoc one) like TEI uses.  Furthermore, it’s better (i.e., more consistent) if musical and text elements behave in the same way, so it doesn’t make sense to adopt the TEI way for text and not for musical elements.  Until a generally useful style language for music notation is available, I believe the current approach is the best option.

If we’re going to allow formatting attributes on musical elements, then why not allow them on text elements as well (for consistency’s sake), especially if their use can be contained to <rend> and a few list-like elements?

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti
Sent: Monday, November 09, 2015 6:57 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] list-related changes

On Mon, Nov 9, 2015 at 6:15 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:

MEI doesn’t mix declarative and procedural markup any more than TEI, does it?

When it comes to text encoding it does - I can't think of a procedural element in TEI. If you can, let me know because it shouldn't be there.

A reasonable mix is necessary for a general-use markup scheme.  Furthermore, I don’t agree that what I’m proposing is procedural markup.  Saying that an item in a list has a bullet or is marked with a Roman numeral isn’t procedural in nature, it’s descriptive.  It’s just as descriptive as using <title>War and Peace</title> to indicate that the content is a title and not a person’s name, just in a different way.

No, <list> and <title> are of the same kind, but the type of bullet is equivalent to saying that titles need to be underlined or double underlined. (There is certainly a semantic difference between ordered and unordered lists, but how they are rendered on the page is a different matter).

I agree that you might not want to use this kind of thing for MEI that describes born-digital material (where the author controls the rendition), but it’s essential for describing already-existing material, especially if it is non-standard in some way, for example if it contains a printing error that caused an item in an otherwise-numbered list to be labelled with an “A”.  How could one possibly *describe* this situation without saying anything about the bullets?  Putting this kind of information in a CSS file is just moving the problem.  The markup no longer contains any information about the bullets, but the CSS does and without it (the CSS) the MEI doesn’t effectively *describe* its source so the two have to be interpreted together.  There’s a false sense of having separated the content and presentation in this case.

I don't disagree, but CSS is a more useful system than mixing in CSS-like values in MEI - which is what has caused my objection to arise. The way TEI handles this is by creating categories: list X is of a special type and has a specific rendition. The rendition is then expressed using adequate systems, not TEI (and the code can be embedded if you want to keep everything in one file). The ODD allows you to document why the special type is needed and how that impacts the rest of your customization. Not saying that this is *the* only way to handle this, but it works.

Raff

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti
Sent: Monday, November 09, 2015 5:29 PM

To: Music Encoding Initiative
Subject: Re: [MEI-L] list-related changes

The bad idea is adding procedural markup to lists.

Text encoding in MEI mixes declarative and procedural markup, particularly through <rend>. I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files.  So I would avoid adding more procedural markup in the text encoding side of MEI.

On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:

I’m not sure what you think is a bad idea or what you mean mean by “already compromised”.  Can you elaborate please?

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti
Sent: Monday, November 09, 2015 5:00 PM

To: Music Encoding Initiative
Subject: Re: [MEI-L] list-related changes

I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output.

Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse.

Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.rendition.html#tei_att.rendition> (and <rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rendition.html>>). In this way you can have the cake and eat it too.

Raff

On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:

Putting the mark in the markup --

[Unicode for bullet] item 1
[Unicode for bullet] item 2
etc.

denies the opportunity to treat the bullet separately from the item content.  Your suggested approach mixes what is presentational with actual content.  That's generally a bad idea.

> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of
> Johannes Kepper
> Sent: Monday, November 09, 2015 4:09 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] list-related changes
>
> I'm sorry to say, but I see no need to include that in MEI. If I want to be
> descriptive, I can include the mark in the encoding itself. But of course you're
> free to convince me and anyone else who's not convinced yet :-)
>
> jo
>
> Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>:
>
> >
> > I'd like to make it easier to control the formatting of lists from within the
> document markup rather than pushing it off entirely to CSS or othe, external
> formatting procedures.
> >
> > To this end, I plan to remove the current @form attribute and create a new
> att.listrend attribute class containing @mark and @order attributes --
> >
> > <attList>
> >   <attDef ident="mark" usage="opt">
> >     <desc>Contains the character string (usually a single character, such as a
> bullet,
> >         box, dash, etc.) that precedes each item in the list.</desc>
> >     <datatype>
> >       <rng:data type="string"/>
> >     </datatype>
> >   </attDef>
> >   <attDef ident="order" usage="opt">
> >     <desc>Indicates the system used to generate the character string (usually
> a single
> >       character) that precedes items in an ordered list.</desc>
> >     <datatype>
> >       <rng:data type="NMTOKEN"/>
> >     </datatype>
> >     <valList type="semi">
> >       <valItem ident="alphalower">
> >         <desc>Lower case letters.</desc>
> >       </valItem>
> >       <valItem ident="alphaupper">
> >         <desc>Upper case letters.</desc>
> >       </valItem>
> >       <valItem ident="arabic">
> >         <desc>Arabic numerals.</desc>
> >       </valItem>
> >       <valItem ident="romanlower">
> >         <desc>Lower case Roman numerals.</desc>
> >       </valItem>
> >       <valItem ident="romanupper">
> >         <desc>Upper case Roman numerals.</desc>
> >       </valItem>
> >     </valList>
> >   </attDef>
> > </attList>
> >
> > Any list without one of these attributes (a list cannot have both) should be
> assumed to be "simple"; that is, without any mark or order.  This is NOT
> procedural markup, just somewhat more descriptive than what used to be
> allowed. J
> >
> > --
> > p.
> > ________________________________
> > Perry Roland
> > University of Virginia
> > P. O. Box 400874
> > Charlottesville, VA, 22904
> > 434-982-2702<tel:434-982-2702> (w)
> > pdr4h (at) virginia (dot) edu
> >
> > _______________________________________________
> > mei-l mailing list
> > mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151111/69536545/attachment.html>