Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

GREEN
closed-fixed
Martin Holmes
9(high)
2014-08-31
2012-10-25
Martin Holmes
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

  • 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 :-)

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

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

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

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

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

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

     
  • 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

     
  • 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).

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

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

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

    an attDef mode="change", that is :-}

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

    fair enough. "ingredients", "dramatis_personae", "syllogism" (I borrow from EEBO)

    --
    Sebastian Rahtz
    Director (Research) of Academic IT
    University of Oxford IT Services
    13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

     
    Last edit: Kevin Hawkins 2013-04-25
    • Martin Holmes
      Martin Holmes
      2013-04-23

      Won't <list type="dramatis_personae"> collide with <castList>?

       
  • Brett Barney
    Brett Barney
    2013-04-23

    Of "ordered," "numbered," and "sequenced," I think "ordered" is the most apt. It seems to me irrelevant whether some specialized domain attaches a restricted meaning to a term (and I'm not convinced, anyway, that "formal linguistics" has a consensus opinion about the nature of lists). Besides the problem with "numbered" that Lou anticipates (that the "numbers" sometimes aren't), it re-introduces rendition into the issue of typology. It's easy enough to think of lists whose items aren't marked by letters, numbers, or anything else but are still ordered. And a good case could be made that lots of lists aren't ordered--my shopping list, for example. "Sequenced" strikes me as just a synonym for "ordered."

     
  • Martin Holmes
    Martin Holmes
    2013-04-23

    One consideration here is minimizing the impact on users. Many will have to consider switching their use of @type to @rend; if we can't agree on what to call what-used-to-be-ordered, shouldn't we just stick with what we have, and minimize the burden?

     
  • On 23 Apr 2013, at 22:32, Martin Holmes martindholmes@users.sf.net
    wrote:

    Won't <list type="dramatis_personae"> collide with <castList>?

    true. bit misleading.

    Sebastian Rahtz
    Director (Research) of Academic IT
    University of Oxford IT Services
    13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

     
    Last edit: Kevin Hawkins 2013-04-25
  • Kevin Hawkins
    Kevin Hawkins
    2013-04-25

    I don't agree with Martin that we should keep changes to a minimum. While we are disrupting things for our users, we might as well take the opportunity to rectify anything else that needs rectifying.

    Still, I agree with Brett that "ordered" is intuitive for most people that we need not be concerned about the restricted meaning of "ordered list" in computer science and possibly formal linguistics.

    For @rend, I would actually prefer if we dropped "ordered" as a suggested value and included "decimal", "lower-roman", and "upper-roman" (or something similar) as some sample values. To me, @rend should more precisely describe rendering in a source document than simply "ordered" (or "sequential"). Even though we are trying to differentiate between @type and @rend, giving something like "ordered" as a sample value continues to blur the distinction because, in my mind at least, there is a strong semantic difference between an ordered and unordered list. If I were composing a document in TEI, in many cases I would happily use @type='ordered' and @type='unordered' to control whether the list should be rendered with some sort of numbering/letter or some sort of bullets. Therefore, I suggest giving the following sample values for @type:

    ordered
    unordered
    gloss
    ingredients
    syllogism

    That will get people started down the path of imagining their own typology of lists.

     
  • Martin Holmes
    Martin Holmes
    2013-04-25

    Surely we just had this discussion at the Council meeting, and decided that "ordered" and "unordered" are not types of list; they relate to rendering. If you want to get into the types of numbering, the way to do it is surely with @style and all the list-style-type values. Lists are inherently ordered, and cannot be otherwise; the distinction between "ordered" and "unordered" which we share with HTML's ul vs ol elements is actually a distinction between numbered-in-some-way and bulleted-in-some-way; and those are rendering things, albeit not very precise.

     
  • Kevin Hawkins
    Kevin Hawkins
    2013-04-25

    Okay, right, the discussion at Council is coming back to me. Sorry for not reviewing the minutes before responding.

    If Council decided that lists are inherently ordered and can't be otherwise (I see where that comes from and partly agree, though I still like the idea of an unordered list), then I retract my previous comment except for the following parts ...

    I don't agree with Martin that we should keep changes to a minimum. While we are disrupting things for our users, we might as well take the opportunity to rectify anything else that needs rectifying.

    Still, I agree with Brett that "ordered" is intuitive for most people that we need not be concerned about the restricted meaning of "ordered list" in computer science and possibly formal linguistics.

     
  • James Cummings
    James Cummings
    2013-11-09

    What remains to be done on this ticket?

     
  • examples all changed @rend to @type, I believe, and the stylesheets supported that. I'd suggest we close this until it comes up again.

     
  • Martin Holmes
    Martin Holmes
    2013-11-10

    Both @rend and @type are still in use in the Glines, and the values "ordered" and "simple" are both used. We even have <list rend="runon" type="ordered">. I think I should do a quick audit of what we're actually doing now, and compare it with what we're advising, then we can decide whether it's worth taking any action or not.

     
  • Martin Holmes
    Martin Holmes
    2013-12-20

    Analysis of usage of list/@type and list/@rend in the Guidelines:

    Our suggested values for list/@type are:

    ordered, bulleted, simple, gloss

    In Guidelines prose, we use:

    list type="gloss": 59
    list type="simple": 107
    list type="ordered": 32
    list rend="simple": 4
    list rend="ordered": 4
    list rend="specList": 1

    In examples:

    list type="ordered": 19
    list type="gloss": 25
    list type="speakers": 8
    list type="simple": 8
    list type="bullets": 3
    list type="unordered": 2
    list type="index": 2
    list type="attendance": 2
    list type="參與者": 1
    list type="inline": 1
    list type="indexentry": 1
    list type="encoders": 3
    list type="編碼員": 1
    list rend="runon": 5

     
  • Martin Holmes
    Martin Holmes
    2013-12-20

    Brief analysis and recommendations sent to Council list 2013-12-20.

     
  • Martin Holmes
    Martin Holmes
    2014-06-30

    Council (2014-06-30) decides this is release blocking. Martin and Syd to carry it out. All of council to read the wiki page and feedback to M & S within a week.

     
  • Martin Holmes
    Martin Holmes
    2014-06-30

    • Group: AMBER --> GREEN
    • Priority: 5 --> 9(high)
     
  • Martin Holmes
    Martin Holmes
    2014-08-01

    In several commits up to 12952, the following changes have been made:

    • list/@type now has only one recommended value, "gloss"
    • the Guidelines prose now recommends the use of @rend rather than @type, with suggested values. This is instead of providing a valList for @rend in list.xml because a) this breaks DTD generation (overriding a member of a global class at the element level), and b) we do not provide valLists for @rend anywhere else.
    • All examples and usage in the Guidelines have been changed to the use of @rend.
    • Sebastian appears to have updated the Stylesheets to handle the new values as well as retaining support for the old.

    This means the ticket is basically complete, but Syd has been tasked by the Council teleconference of 2014-08-01 to read the relevant Guidelines prose section (3.7) and perhaps strengthen the recommendation to use @rendition or @style rather than @rend. We need to strike a balance between providing an easy update path (@rend) for people who were used to using @type, and recommending a better approach (@rendition/@style) which requires more knowledge (<rendition> and CSS).

     
    Last edit: Martin Holmes 2014-08-01
  • James Cummings
    James Cummings
    2014-08-01

    I wonder whether we should have another 'type' of list provided of 'simple' or something. Or is that just stating the obvious when it is just a basic list of items.

     
  • Lou Burnard
    Lou Burnard
    2014-08-01

    list="inline" ?
    for things like "my favourite fruit are apples, oranges, and bananas"

     
  • James Cummings
    James Cummings
    2014-08-01

    No, 'inline' is a form of rendition. I might equally render that as:

    "My favourite fruit are
    - apples,
    - oranges,
    - and bananas

    but really blueberries are better than all of those."

     
  • Martin Holmes
    Martin Holmes
    2014-08-01

    list/@type="simple" suggests to me that it's a list of simple things. We already have @rend="simple" (no markers, numbers etc.).

    It's easy to think of different types of list, but there's no imaginable justification for selecting some of them from the possible millions and making them suggested values; the only reason "gloss" is in there is that it involves a very specific and complicated use of list markup, with implications for other elements used, which is exemplified at length in the Guidelines.

     
  • Lou Burnard
    Lou Burnard
    2014-08-01

    I tend to agree with Martin, but I do think that the "my favourite fruit" kind of list is a different kind, not because of its formatting, but because of its status with respect to the text around it. Maybe "runon" or "embedded" would be better names. (I claim that James's version would be @type="runon" rend="bulleted")

     
  • Martin Holmes
    Martin Holmes
    2014-08-01

    We can't, surely, have @type used simultaneously, in the same suggested valList, to characterize what sort of things are in the list (glosses) and what sort of appearance the list has (runon/inline). That's the source of all these problems in the first place. I don't see the difference between inline and runon, myself, but if there is one, there's nothing to prevent users from characterizing it through either @type or @rend or both; but I want to avoid recommending or exemplifying any usage which is confusingly borderline like this. Let's keep it clean.

     
  • Martin Holmes
    Martin Holmes
    2014-08-04

    Following suggestions from Paul, I've now added "index", "instructions", "litany" and "syllogism" to the suggested value list for list/@type, along with a couple of examples from his post. I think this provides a more helpful set of examples from which it's much clearer what the purpose of @type is, in contrast with @rend.

     
  • Martin Holmes
    Martin Holmes
    2014-08-31

    Following Council discussions, I've removed the override of @rend from the list.xml spec. We will stick with suggestions in the prose chapter. I think this ticket is now done.

     
  • Martin Holmes
    Martin Holmes
    2014-08-31

    • status: open --> closed-fixed
     
  • Martin Holmes
    Martin Holmes
    2014-08-31

    Final change (removal of @rend override) committed in rev 12972.