[MEI-L] list-related changes

Raffaele Viglianti raffaeleviglianti at gmail.com
Wed Nov 11 23:59:39 CET 2015 

You're right, TEI's system wouldn't fit well musical systems and indeed I
didn't suggest to use it for those.

However, I don't think we need consistency between styling of text and
music elements: they do behave quite differently as you pointed out.

On the other hand, I'm not sure text encoding in MEI really needs to be too
all-encompassing. That's also why having an attribute class for list item
bullet type seems out of scope to me.

Raff
On Nov 11, 2015 5:36 PM, "Roland, Perry D. (pdr4h)" <
pdr4h at eservices.virginia.edu> wrote:

>
>
> 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> 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] *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
> <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
>
>
>
>
> _______________________________________________
> 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/20151111/048c584a/attachment.html>

More information about the mei-l mailing list