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