[MEI-L] list-related changes
Raffaele Viglianti
raffaeleviglianti at gmail.com
Tue Nov 10 00:56:31 CET 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151109/dd82b1cc/attachment.html>
More information about the mei-l
mailing list