[MEI-L] list-related changes

Tue Nov 10 00:15:42 CET 2015

MEI doesn’t mix declarative and procedural markup any more than TEI, does it?  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.

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.

--
p.

From: mei-l [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

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