Sourceforge is currently down, so I'm posting this here in lieu of a bug report. Will transfer it to a ticket assigned to me later. --------- The remarks associated with att.global.rendition say Where both @rendition and @rend are supplied, the latter is understood to override or complement the former. This seems correct to me. The prose of section 1.3.1.1.3 "Rendition Indicators" says In the TEI scheme, it is possible to supply information about the appearance of elements within a source document in the following distinct ways: 1. One or more properties may be specified as the default for all elements of a given type, using the @render attribute to point to rendition elements ; 2. One or more properties may be specified for individual element occurrences, using the @rend attribute with any convenient set of one or more sequence-indeterminate tokens; 3. One or more properties may be specified for individual element occurrences, using the @rendition attribute to point to rendition elements; 4. One or more properties may be supplied explicitly for individual element occurrences, using the @style attribute. If the same property is specified in more than one of the above ways, the one with the highest number in the list above is understood to be applicable. At the very least, 2 & 3 should be reversed, and use of the @selector of <rendition> needs to be added to the list. But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash. And why does @style override @rend? I think I'd prefer the reverse (but I'm not sure). Typo: extra space before semicolon in <item> #1.
But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; @rend is defined as 1 to inifinity of data.word ... when council has discussed this in the past consensus was that it cannot and should not be a phrase containing whitespace but a set of tokens. e.g. "big blue wiggly" vs "This text is written big and blue and wiggly". Perhaps 'token' is not the correct word here, but whitespace separated discrete values. Otherwise we are reversing
On 18/07/15 04:43, Syd Bauman wrote: Not necessarily disagreeing with the discussion on order. The basic choice is whether locally specified magic words are to be considered closer to the encoder's intention than those translated to a formal description language. But I wanted to comment on this: the sensible war on text bearing attributes.
and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash.
If I'm understanding correctly, I would strongly disagree with you on this. I firmly believe that rend="big blue wiggly" is and must be considered the same as rend="blue wiggly big". This is a set of magic words (hopefully documented in the ODD) and no precedence or structure should be intended by their order. 'Sequence indeterminate' might be a confusing way to say that, but I'm assuming it means that there is no determined order to the sequence of whitespace separated strings. i.e. that they can be given in any order and mean the same thing.
And why does @style override @rend? I'm not sure.
I think I'd prefer the reverse (but I'm not sure).
I could be convinced of that. In the difference between formally specified language and project-specific magic words, perhaps it is the latter which should be considered of higher value even though the former may be more easily useful. I'm not sure any should override any. Let's say I have: <hi rend="mySpecialFormat" rendition="#specialFormatNumber2" style="float:left;clear:both;color:red;">text</hi>. What does that mean? Why should one stylistic thing take precedence over another? Why shouldn't it all be additive? i.e. This is in mySpecialFormat, whatever this is, and that is further documented by the CSS in #specialFormatNumber2 and in addition it is floated left and red. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
In the difference between formally specified language and project-specific magic words, perhaps it is the latter which should be considered of higher value even though the former may be more easily useful. I'm not sure any should override any. Let's say I have: <hi rend="mySpecialFormat" rendition="#specialFormatNumber2" style="float:left;clear:both;color:red;">text</hi>. What does that mean? Why should one stylistic thing take precedence over another? Why shouldn't it all be additive? i.e. This is in mySpecialFormat, whatever this is, and that is further documented by the CSS in #specialFormatNumber2 and in addition it is floated left and red.
If you mean additive in the CSS sense, then the order of addition is crucial, at least when conflicting property values appear. If one component specifies block display and centre alignment, whereas another specifies inline display, whichever is last will win, at least in CSS, unless !important is also in the mix somehow. This may be the root of Syd's concern about "sequence indeterminate", although I agree with you that we really shouldn't allow the order of whitespace-separated tokens in an attribute value to be significant. Syd is presumably arguing for @rend to function as @n does ("The value of this attribute is always understood to be a single token, even if it contains space or other punctuation characters..."). I would not like to see that -- like you, I think it would be a step backwards. If you want to describe the appearance of something in running prose, the solution is @rendition -> <rendition>. Cheers, Martin On 15-07-18 07:16 AM, James Cummings wrote:
On 18/07/15 04:43, Syd Bauman wrote:
Not necessarily disagreeing with the discussion on order. The basic choice is whether locally specified magic words are to be considered closer to the encoder's intention than those translated to a formal description language. But I wanted to comment on this:
But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; @rend is defined as 1 to inifinity of data.word ... when council has discussed this in the past consensus was that it cannot and should not be a phrase containing whitespace but a set of tokens. e.g. "big blue wiggly" vs "This text is written big and blue and wiggly". Perhaps 'token' is not the correct word here, but whitespace separated discrete values. Otherwise we are reversing the sensible war on text bearing attributes.
and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash.
If I'm understanding correctly, I would strongly disagree with you on this. I firmly believe that rend="big blue wiggly" is and must be considered the same as rend="blue wiggly big". This is a set of magic words (hopefully documented in the ODD) and no precedence or structure should be intended by their order. 'Sequence indeterminate' might be a confusing way to say that, but I'm assuming it means that there is no determined order to the sequence of whitespace separated strings. i.e. that they can be given in any order and mean the same thing.
And why does @style override @rend? I'm not sure.
I think I'd prefer the reverse (but I'm not sure).
I could be convinced of that. In the difference between formally specified language and project-specific magic words, perhaps it is the latter which should be considered of higher value even though the former may be more easily useful. I'm not sure any should override any. Let's say I have: <hi rend="mySpecialFormat" rendition="#specialFormatNumber2" style="float:left;clear:both;color:red;">text</hi>. What does that mean? Why should one stylistic thing take precedence over another? Why shouldn't it all be additive? i.e. This is in mySpecialFormat, whatever this is, and that is further documented by the CSS in #specialFormatNumber2 and in addition it is floated left and red.
-James
Sorry for the delay, folks. A full boot volume caused my system to hang horribly. Not much of a problem, except it is an 80 km drive away. Sigh. Anyway, I'm afraid you haven't got my (adamant) complaint about @rend quite right, and I think the position being taken (that the individual tokens necessarily are self-contained and not ordered) is nuts. The definition of @rend is 1+ of data.word entirely for syntactic reasons.[1] It was never meant to imply that each of the "words" was a "magic token" of any kind, or that whitespace is not significant because it is used to separate tokens. It was *only* meant to disallow certain characters (like non-spacing or combining marks, or control characters). data.word does *exactly* the right thing, except it does not allow whitespace, which we wanted. So allowing 1+ allows whitespace. That's it. No other implications.[2] If we wanted @rend to be "a set of tokens. e.g. 'big blue wiggly' ... whitespace separated discrete values" as James suggests, we would have made it 1+ of data.enumerated. I am regretting very much that we did not make a new datatype for this purpose, just to avoid people falling into the pitfall of thinking there is significance to oneOrMore data.word where there is none. (Said datatype would be defined, I think, as xsd:token { pattern = "(\p{L}|\p{N}|\p{P}|\p{S}|\p{Z}| | | || |…)+" } i.e., exactly as data.word but also allowing separator characters and those control characters considered whitespace; no need for the 1+ bit anymore. :-) I'll post on the need for intra-value order soon. Notes ----- [1] And to be honest, I'm starting to regret that I pushed for it that way. [2] That is slightly disingenuous of me. There is one other implication which, at the time, I suggested was important. That is to allow whitespace normalization before comparison for purposes of validation. I.e., not only is "a b c" valid, but so is " a b c". This would still have been true if @rend had been defined instead as "string" or "token", but IIRC in that case would cause problems if a user added constraints (via facets) to the value. Martin Holmes writes:
In the difference between formally specified language and project-specific magic words, perhaps it is the latter which should be considered of higher value even though the former may be more easily useful. I'm not sure any should override any. Let's say I have: <hi rend="mySpecialFormat" rendition="#specialFormatNumber2" style="float:left;clear:both;color:red;">text</hi>. What does that mean? Why should one stylistic thing take precedence over another? Why shouldn't it all be additive? i.e. This is in mySpecialFormat, whatever this is, and that is further documented by the CSS in #specialFormatNumber2 and in addition it is floated left and red.
If you mean additive in the CSS sense, then the order of addition is crucial, at least when conflicting property values appear. If one component specifies block display and centre alignment, whereas another specifies inline display, whichever is last will win, at least in CSS, unless !important is also in the mix somehow.
This may be the root of Syd's concern about "sequence indeterminate", although I agree with you that we really shouldn't allow the order of whitespace-separated tokens in an attribute value to be significant. Syd is presumably arguing for @rend to function as @n does ("The value of this attribute is always understood to be a single token, even if it contains space or other punctuation characters..."). I would not like to see that -- like you, I think it would be a step backwards. If you want to describe the appearance of something in running prose, the solution is @rendition -> <rendition>.
Cheers, Martin
On 15-07-18 07:16 AM, James Cummings wrote:
On 18/07/15 04:43, Syd Bauman wrote:
Not necessarily disagreeing with the discussion on order. The basic choice is whether locally specified magic words are to be considered closer to the encoder's intention than those translated to a formal description language. But I wanted to comment on this:
But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; @rend is defined as 1 to inifinity of data.word ... when council has discussed this in the past consensus was that it cannot and should not be a phrase containing whitespace but a set of tokens. e.g. "big blue wiggly" vs "This text is written big and blue and wiggly". Perhaps 'token' is not the correct word here, but whitespace separated discrete values. Otherwise we are reversing the sensible war on text bearing attributes.
and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash.
If I'm understanding correctly, I would strongly disagree with you on this. I firmly believe that rend="big blue wiggly" is and must be considered the same as rend="blue wiggly big". This is a set of magic words (hopefully documented in the ODD) and no precedence or structure should be intended by their order. 'Sequence indeterminate' might be a confusing way to say that, but I'm assuming it means that there is no determined order to the sequence of whitespace separated strings. i.e. that they can be given in any order and mean the same thing.
And why does @style override @rend? I'm not sure.
I think I'd prefer the reverse (but I'm not sure).
I could be convinced of that. In the difference between formally specified language and project-specific magic words, perhaps it is the latter which should be considered of higher value even though the former may be more easily useful. I'm not sure any should override any. Let's say I have: <hi rend="mySpecialFormat" rendition="#specialFormatNumber2" style="float:left;clear:both;color:red;">text</hi>. What does that mean? Why should one stylistic thing take precedence over another? Why shouldn't it all be additive? i.e. This is in mySpecialFormat, whatever this is, and that is further documented by the CSS in #specialFormatNumber2 and in addition it is floated left and red.
-James
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Syd Bauman, EMT-Paramedic Senior XML Programmer/Analyst Northeastern University Women Writers Project s.bauman@neu.edu or Syd_Bauman@alumni.Brown.edu
On the need for intra-value order in @rend (and friends) ... I think it is *absolutely necessary* that people be allowed to consider the order of things inside @rend to be relevant: 1) for consistency (important) 2) for processing (important) 3) for expressivity (very important, if not necessary) 4) to continue to support existing TEI projects (politically required) (1) for consistency --- --- ----------- The difference between @rend and @style is that the latter is expressed in a style definition language declared in <styleDefDecl> (and typically CSS), whereas the former is project-defined. Very clearly on @style order matters. As a simple (and stupid) example, consider style="font-size: 50%; font-size:200%;" vs style="font-size: 200%; font-size:50%;" Since order can matter inside @style, order should matter inside @rend (unless, of course, the project-specific system does not care about order, and then it doesn't). (2) for processing --- --- ---------- It is quite reasonable that a stylesheet would try to ascertain the rendition of an element by assembling the various bits that talk about its rendition in the right order.[1] If they are assembled and read L to R, the processor need not worry about repetition of certain features, as long as something read later overrides what is specified earlier. But this processing model would become weird if the processor had to think of the bits specified on @rend is not in order, whereas everything else is in order. (BTW, I'm not suggesting this is the only processing model one could use, only that it is one we should not deliberately make more difficult.) (3) for expressivity --- --- ------------ Let's say I've made up my own language for the content of <rendition> and the value of @rend, and that I've chosen to express delimiters as renditional features, not transcribed characters. (And note, both of these things are true at the WWP.) So the stage direction "[Aside]" becomes <stage rend="startDelim='[', endDelim=']'">Aside</stage> If the word "Aside" were in italics, I would have something like <stage rend="startDelim='[', endDelim=']', italics">Aside</stage> But what if the the square brackets were also in italics? Then <stage rend="italics, startDelim='[', endDelim=']'">Aside</stage> could be used to assert that. What if only the ending square bracket were in italics? Then <stage rend="startDelim='[', italics, endDelim=']'">Aside</stage> So order is really helpful, if not required, to express what was on the page. (And yes, this system would require a keyword for "not in italics" to express that the starting square bracket and "Aside" were in italics, but the closing square bracket was not.) (4) to continue to support existing TEI projects --- -- -------- -- ------- -------- --- -------- Any project that uses the WWP "rendition ladder" system (for which there is some software support, although not much; and which was adopted, over my mild objection, as a best practice by the TEI in Libraries task force) requires that the pieces of @rend not be thought of as space-separated tokens, and that order be significant. Period. Notes ----- [1] I would say "the right order" is: * content of <rendition>s selected by their @select, in document order * content of <rendition> selected by a <tagUsage> that points to it * content of <rendition> selected by an applicable @rendition * value of @style * value of @rend but we can worry about that detail later.
On 7/19/15 11:42 PM, Syd Bauman wrote:
(4) to continue to support existing TEI projects --- -- -------- -- ------- -------- --- -------- Any project that uses the WWP "rendition ladder" system (for which there is some software support, although not much; and which was adopted, over my mild objection, as a best practice by the TEI in Libraries task force) requires that the pieces of @rend not be thought of as space-separated tokens, and that order be significant. Period.
For the record, while rendition ladders were recommended in versions 1.0 to 2.1 of the "best practices" document, that recommendation was removed in version 3.0, published in 2011. Kevin
On 20/07/15 14:56, Kevin Hawkins wrote:
On 7/19/15 11:42 PM, Syd Bauman wrote:
(4) to continue to support existing TEI projects --- -- -------- -- ------- -------- --- -------- Any project that uses the WWP "rendition ladder" system (for which there is some software support, although not much; and which was adopted, over my mild objection, as a best practice by the TEI in Libraries task force) requires that the pieces of @rend not be thought of as space-separated tokens, and that order be significant. Period.
For the record, while rendition ladders were recommended in versions 1.0 to 2.1 of the "best practices" document, that recommendation was removed in version 3.0, published in 2011.
Partly, if I'm remembering correctly, as a result of the Council coming to the decision that they should be considered whitespace separated tokens and the order not be considered significant since we now had @rendition as a more formal means of expressing such things. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 7/20/15 9:30 AM, James Cummings wrote:
On 20/07/15 14:56, Kevin Hawkins wrote:
On 7/19/15 11:42 PM, Syd Bauman wrote:
(4) to continue to support existing TEI projects --- -- -------- -- ------- -------- --- -------- Any project that uses the WWP "rendition ladder" system (for which there is some software support, although not much; and which was adopted, over my mild objection, as a best practice by the TEI in Libraries task force) requires that the pieces of @rend not be thought of as space-separated tokens, and that order be significant. Period.
For the record, while rendition ladders were recommended in versions 1.0 to 2.1 of the "best practices" document, that recommendation was removed in version 3.0, published in 2011.
Partly, if I'm remembering correctly, as a result of the Council coming to the decision that they should be considered whitespace separated tokens and the order not be considered significant since we now had @rendition as a more formal means of expressing such things.
The Council discussion was in 2012, after the "best practices" were last revised: http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml#body.1_div.3_div.... --Kevin
Thank you for that pointer, Kevin. As far as I'm concerned, Council made a corrigible error. It was out of line to take an attribute that has been declared as completely free text for ~18 years, and then as free text with no obviously stupid characters that no one would want anyway for another 5 years, and suddenly change it to something entirely different (and, unless I missed more than I thought, without any deprecation). Maybe I'll see things differently after the temperature in here drops below 27 C, but right now it seems to me the value *and syntax* of @rend is user-defined. Period. The only recourse I see is to revert this decision and apologize.
As a simple (and stupid) example, consider style="font-size: 50%; font-size:200%;" vs style="font-size: 200%; font-size:50%;"
Since order can matter inside @style
I think this is a little disingenuous. @style (if it is CSS) contains a single ruleset; a duplicate property occurring in a ruleset would normally be considered either an error or a workaround of some kind to handle browser support issues. It's common to override property values in rulesets further down the cascade--i.e. in a different ruleset that is applied later--but I think a @style value constitutes a single ruleset. Cheers, Martin On 2015-07-19 09:42 PM, Syd Bauman wrote:
On the need for intra-value order in @rend (and friends) ...
I think it is *absolutely necessary* that people be allowed to consider the order of things inside @rend to be relevant: 1) for consistency (important) 2) for processing (important) 3) for expressivity (very important, if not necessary) 4) to continue to support existing TEI projects (politically required)
(1) for consistency --- --- ----------- The difference between @rend and @style is that the latter is expressed in a style definition language declared in <styleDefDecl> (and typically CSS), whereas the former is project-defined. Very clearly on @style order matters. As a simple (and stupid) example, consider style="font-size: 50%; font-size:200%;" vs style="font-size: 200%; font-size:50%;"
Since order can matter inside @style, order should matter inside @rend (unless, of course, the project-specific system does not care about order, and then it doesn't).
(2) for processing --- --- ---------- It is quite reasonable that a stylesheet would try to ascertain the rendition of an element by assembling the various bits that talk about its rendition in the right order.[1] If they are assembled and read L to R, the processor need not worry about repetition of certain features, as long as something read later overrides what is specified earlier. But this processing model would become weird if the processor had to think of the bits specified on @rend is not in order, whereas everything else is in order. (BTW, I'm not suggesting this is the only processing model one could use, only that it is one we should not deliberately make more difficult.)
(3) for expressivity --- --- ------------ Let's say I've made up my own language for the content of <rendition> and the value of @rend, and that I've chosen to express delimiters as renditional features, not transcribed characters. (And note, both of these things are true at the WWP.) So the stage direction "[Aside]" becomes <stage rend="startDelim='[', endDelim=']'">Aside</stage> If the word "Aside" were in italics, I would have something like <stage rend="startDelim='[', endDelim=']', italics">Aside</stage> But what if the the square brackets were also in italics? Then <stage rend="italics, startDelim='[', endDelim=']'">Aside</stage> could be used to assert that. What if only the ending square bracket were in italics? Then <stage rend="startDelim='[', italics, endDelim=']'">Aside</stage> So order is really helpful, if not required, to express what was on the page. (And yes, this system would require a keyword for "not in italics" to express that the starting square bracket and "Aside" were in italics, but the closing square bracket was not.)
(4) to continue to support existing TEI projects --- -- -------- -- ------- -------- --- -------- Any project that uses the WWP "rendition ladder" system (for which there is some software support, although not much; and which was adopted, over my mild objection, as a best practice by the TEI in Libraries task force) requires that the pieces of @rend not be thought of as space-separated tokens, and that order be significant. Period.
Notes ----- [1] I would say "the right order" is: * content of <rendition>s selected by their @select, in document order * content of <rendition> selected by a <tagUsage> that points to it * content of <rendition> selected by an applicable @rendition * value of @style * value of @rend but we can worry about that detail later.
participants (4)
-
James Cummings -
Kevin Hawkins -
Martin Holmes -
Syd Bauman