[MEI-L] list-related changes

[Johannes Kepper]

I'm not suggesting to do that – I'm just saying that it's possible. And that your well-known naive encode might take this approach anyway. What concerns me is that while you claim your proposal isn't procedural, I strongly believe it is. I have no problem to include something along these lines in MEI, but I wouldn't want to call it descriptive when it's not…



Am 09.11.2015 um 22:31 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:

> 
> 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

-------------- 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/20151109/b97ff416/attachment.sig>