#460 list/@type="unordered" is not recommended, but used often

GREEN
closed-fixed
9(high)
2014-08-31
2012-10-25
No

The definition of list/@type suggests these values:

ordered
list items are numbered or lettered.
bulleted
list items are marked with a bullet or other typographic device.
simple
list items are not numbered or bulleted. [Default]
gloss
each list item glosses some term or concept, which is given by a label element preceding the list item.

However, the stylesheets are peppered with uses of "unordered" (which used to be in there, but is not any more). These should be replaced with "bulleted", presumably.

Related

Bugs: #460

Discussion

1 2 3 > >> (Page 1 of 3)
  • Martin Holmes

    Martin Holmes - 2012-10-25

    I had no intention of pre-emptively assigning this to Sebastian. Did he take it, or did I do it by accident? Either way, James or Sebastian, feel free to dump it back to me if you want.

     
  • Piotr Banski

    Piotr Banski - 2012-10-25

    The "XSLT stylesheets" category caused the automatic assignment to Sebastian, and for a reason :-)

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-10-25

    I'd say change the guidelines. "bulleted" is a bad recommended value, in my opinion, and not a good alternate to "ordered". I also think having "simple" as the default is simply barking - how
    many lists do you see which are neither numbered nor bulleted?

    I think we have an earlier ticket from John McCaskey on this subject.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-10-25

    I also claim the Stylesheets have might over right. They've been supporting "unordered" not "bulleted" for over 10 years, and no-one has ever complained.....

     
  • John P. McCaskey

    Yes. The earlier ticket, 3548625, was rejected. The discussion there might still be helpful though.

     
  • Martin Holmes

    Martin Holmes - 2012-10-26

    This is on the list for things to think about for P6:

    http://wiki.tei-c.org/index.php/P6-dev

    But I think it's a bit backwards to say that we made a decision for P5 and implemented it, but because that implementation wasn't yet carried over to the stylesheets, we should reverse it.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-10-26

    The decision was not to go with John's more extensive review of how list appearances work. It did not, I think, discuss the existing arbitrary list of values? ie bulleted vs unordered.

    Looking at the Guidelines source again (I probably did this before):

    ./Source/Guidelines/en/HD-Header.xml:<list type="bullets">
    ./Source/Guidelines/en/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Guidelines/en/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Guidelines/en/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Guidelines/fr/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Guidelines/fr/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Guidelines/fr/IN-RulesForInterchange.xml:<list type="bullets">
    ./Source/Specs/item.xml: <list type="unordered">
    ./Source/Specs/list.xml: <item>a candlestick maker, with <list type="bullets"><item>rings on his fingers</item><item>bells on his toes</item></list>
    ./Source/Specs/list.xml: <list type="unordered">
    ./Source/Specs/list.xml: <list type="bullets">

    from which I conclude that
    a) we dont use bulleted, we use bullets.
    b) we do use unordered
    c) our suggest valList is a NONSENSE

     
  • Lou Burnard

    Lou Burnard - 2012-11-04

    The suggested valList is not a NONSENSE. It is based on the observation that every doc preparation system known to man (or woman) offers a choice between labelling list items with a sequence number, with some sort of splodge, with a variable label, or with nothing at all. It suggests some appropriate names for each of these (perhaps "numbered" or "sequenced" would be better than "ordered" since lists are by definition ordered, but then people will say that "a, b, c, d" are not numbering)

    You could more plausibly argue that both practice in the encoding of the Guidelines and facilities offered by the Stylesheet libraries are NONSENSE, since they don't follow the suggested names. But that is hardly their fault, since the names were only settled on recently.

    We can, and I think should, make practice in the Guidelines consistent with the proposed valList, modulo any suggested change in it; we should also make sure the Stylesheets support that recommended set of values. At what stage the Stylesheets stop supporting other possible values is up to their maintainer...

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-11-04

    well, yes, I meant the combination of the practice of the Guidelines and the <valList> together makes a nonsense. We should change one or the other. I would say we should recommended and use "ordered", "unordered" and "gloss" and (even more importantly) decide what on earth we mean by "simple". Where are these lists which have no number or symbol of any kind attached to an item? is that really the default situation?

    I would avoid both "bullet" and "number" in the names, as this implies something about rendition. As you say, "a", "b", "c" are not numbers, and (eg) pointing hands or dashes are not bullets.

    obviously having the XSLT support the values in the <valList> is the easiest bit.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-05
    • milestone: --> RED
     
  • Martin Holmes

    Martin Holmes - 2013-01-05

    I see this was set to red, but I hope that doesn't result in its getting lost. We have a manifest inconsistency in the Guidelines at the moment, so we should get that fixed asap. We should make sure this is on the list for discussion at the next ftf.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-05

    i think it has to be RED, because there is no simple agreed solution. I do agree it needs a f2f discusson and decision

     
  • Lou Burnard

    Lou Burnard - 2013-01-19

    Making practice in the Guidelines consistent should not be very hard though. Here's the complete list of @type values currently used and their frequencies

    attendance 2
    bullets 4
    encoders 3
    gloss 85
    index 2
    indexentry 1
    inline 1
    ordered 57
    simple 119
    speakers 8
    unordered 2
    參與者 1
    編碼員 1

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-20

    I'd certainly be in favour of getting rid of type=bullets, easy enough. Its the type="simple" ones which a bit harder. According to the Spec, this means "simplelist items are not numbered or bulleted. ". Given the the Glines are a born-digital document, what does this mean? how should they be rendered, and how do you know there are a list if they have no number or symbol prefix? how do you know where items stop and start?

    It seems highly likely to me that type="simple" actually means "ordered"....

    I'll say again that I think the presence of "bullets" (as opposed to asterisks, emdashes, or arrows) should be encoding using @rend, and has no place in @type

     
  • Martin Holmes

    Martin Holmes - 2013-01-20

    "simple" is rendered as bullets in the Guidelines rendering, and it's clear from the contexts that "ordered" was not intended by the author (see for instance the lists of board and council members in the Preface).

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-20

    yes, sorry, i meant "unordered" for "simple".

     
  • Lou Burnard

    Lou Burnard - 2013-02-06

    In the Guidelines, the only thing that matters is the distinction between explicitly numbered lists (which should be and I think all are @type="ordered"), glossary lists (which are all @type="gloss") and lists which are not numbered, which are variously @type="bullets", @type="unordered" and @type="simple" and @type="". Clearly we should make these consistent, and I propose that the easiest way of doing so would be to make them all either "simple" or "". My preference would be for the latter.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-02-06

    if we all agree that "ordered" and "gloss" make sense, then it seems to me we should promote and use "unorderded" rather than "simple". Why, you ask? cos a) whats the difference between "simple" and "unordered", and b) most modern systems make the ordered/unordered distinction, so we might as well use that vocabulary

    if of course someone can find a beautiful example of a simple list which is neither ordered not unordered, i'd like to see it...

     
  • Martin Holmes

    Martin Holmes - 2013-02-06

    One question is whether "unordered" = "bulleted". That's the case with HTML. We might argue that we're not interested in rendering here -- that bulleted vs numbered etc. should be expressed through @rend and @style, and now that we have @style, that's especially easy. But that leaves me wondering what "ordered" means, if not some kind of numbering.

     
  • Martin Holmes

    Martin Holmes - 2013-04-12
    • assigned_to: Sebastian Rahtz --> Martin Holmes
    • Group: RED --> AMBER
     
  • Martin Holmes

    Martin Holmes - 2013-04-12

    Providence meeting: action on MH to spell out the steps of the proposal to change from @type to @rend in our recommendations and our guidelines practice, and to build in support for this in the stylesheets. On Council's approval, go ahead. Changed from Red to Amber. No objections raised at Council meeting.

     
  • Martin Holmes

    Martin Holmes - 2013-04-14

    Wrote some XSLT to convert list/@type when not in egXML, and converted and committed the AB chapter as a test. This will result in all numeric character entities being resolved to their literal characters, but I don't think that will be a problem; wrote to Council to confirm they're OK with it.

     
  • Martin Holmes

    Martin Holmes - 2013-04-23

    Changes have already been made in our Guidelines practice. This was the easy bit. The next stage is to come up with a proposal for changing our recommendations. Currently, we provide suggested values for @type which mix the renditional with a single justifiable type:

    ~~~~~~~~
    ordered
    list items are numbered or lettered.
    bulleted
    list items are marked with a bullet or other typographic device.
    simple
    list items are not numbered or bulleted. [Default]
    gloss
    each list item glosses some term or concept, which is given by a label element preceding the list item.
    ~~~~~~~

    I recommend that we do three things:

    1. Add an attDef for @rend on <list>, and move the values "ordered", "bulleted" and "simple" into there as suggested values for @rend.

    2. Remove the suggested values for list/@type completely, leaving @type without any suggested values, but providing some examples of reasonable values in the description. I don't believe that we can come up with more than a couple of generic values for @type which have any broad application, but some instances of real values ("gloss", "ingredients", "steps" perhaps) would help to point up the difference between renditional and typological features.

    3. Clarify this distinction again in the remarks for <list>, and explain that our recommendations have changed in this respect.

     
  • Lou Burnard

    Lou Burnard - 2013-04-23

    Sorry, I think I may be repeating myself, but just for the record, I
    really don't like "ordered". In formal linguistics all lists are
    ordered, that's the definition of a list (otherwise it's a bag). What's
    wrong with "numbered"? You will say that (a) (b) (c) are not numbers,
    but surely they are being used as such, just like "i", "ii", "iii". If
    you insist, how about "sequenced"?

    On 23/04/13 19:29, Martin Holmes wrote:

    Changes have already been made in our Guidelines practice. This was
    the easy bit. The next stage is to come up with a proposal for
    changing our recommendations. Currently, we provide suggested values
    for @type which mix the renditional with a single justifiable type:

    ordered
    list items are numbered or lettered.
    bulleted
    list items are marked with a bullet or other typographic device.
    simple
    list items are not numbered or bulleted. [Default]
    gloss
    each list item glosses some term or concept, which is given by a label element preceding the list item.

    I recommend that we do three things:

    1.

    Add an attDef for @rend on |<list>|, and move the values
    "ordered", "bulleted" and "simple" into there as suggested values
    for @rend.
    

    2.

    Remove the suggested values for list/@type completely, leaving
    @type without any suggested values, but providing some examples of
    reasonable values in the description. I don't believe that we can
    come up with more than a couple of generic values for @type which
    have any broad application, but some instances of real values
    ("gloss", "ingredients", "steps" perhaps) would help to point up
    the difference between renditional and typological features.
    

    3.

    Clarify this distinction again in the remarks for |<list>|, and
    explain that our recommendations have changed in this respect.
    

    [bugs:#460] http://sourceforge.net/p/tei/bugs/460/
    list/@type="unordered" is not recommended, but used often

    Status: open
    Labels: XSLT stylesheets
    Created: Thu Oct 25, 2012 07:55 PM UTC by Martin Holmes
    Last Updated: Sun Apr 14, 2013 03:20 AM UTC
    Owner: Martin Holmes

    The definition of list/@type suggests these values:

    ordered
    list items are numbered or lettered.
    bulleted
    list items are marked with a bullet or other typographic device.
    simple
    list items are not numbered or bulleted. [Default]
    gloss
    each list item glosses some term or concept, which is given by a label
    element preceding the list item.

    However, the stylesheets are peppered with uses of "unordered" (which
    used to be in there, but is not any more). These should be replaced
    with "bulleted", presumably.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/tei/bugs/460/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #460

    • Martin Holmes

      Martin Holmes - 2013-04-23

      I don't care one way or the other whether the term is "ordered" or "numbered". We have "ordered" all over the place, so that's what I stuck with. My main concern is that whatever we call them, they're renditional and not typological.

       
1 2 3 > >> (Page 1 of 3)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks