[MEI-L] list-related changes

[Raffaele Viglianti]

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> 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] *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> 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] 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>:
> >
> > >
> > > 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 (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
>
>
> _______________________________________________
> mei-l mailing list
> 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
> 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/853c3dfb/attachment.html>