[MEI-L] list-related changes
Johannes Kepper
kepper at edirom.de
Tue Nov 10 00:27:59 CET 2015
Am 10.11.2015 um 00:15 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:
>
> 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.
I see your point, and from a certain point of view, you're right. However, your proposal consists of two attributes, to be attached to the list (if I got that right). I don't understand how these will help to override a general rule in case of a "strange" bullet on one item which doesn't follow the rule. Also, I wonder if we're really able to easily come up with a satisfying list of numbering schemes – especially when we try to describe all kinds of historical manuscripts. Your suggested values cover the creativity of today's CSS specification, but what about the creativity of medieval copyists? Can we really classify that? This was my motivation to put the shape of the bullets into the markup itself. Maybe what we need is an element that identifies its content as bullet – but this feels strange, as we're getting pretty close to TEI land here…
>
> --
> 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> 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 (and <rendition>). 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
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151110/5a235b1d/attachment.sig>
More information about the mei-l
mailing list