Menu
▾
▴
#460 list/@type="unordered" is not recommended, but used often
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
Discussion
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.
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.
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
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.
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
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
"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".
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...
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.
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.
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.
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:
Add an attDef for @rend on
<list>, and move the values "ordered", "bulleted" and "simple" into there as suggested values for @rend.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.
Clarify this distinction again in the remarks for
<list>, and explain that our recommendations have changed in this respect.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:
Related
Bugs:
#460I 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.