Hi Syd, They can't possibly be using @part="N" to say "I can't tell if this is a fragment or not", because it _also_ simultaneously means "not a fragment". We're in a situation where the very definition of the value (as it was before I fixed it) was completely useless, because it had two contradictory meanings at the same time. Anyone who was using it for either meaning was both right and wrong at the same time, and no-one could draw any conclusion from the presence or absence of that attribute value. If you'd like me to check with TEI-L to see if anyone actually was using it, I'll happily do that; but we can't possibly allow the situation as it was to continue. Cheers, Martin On 2015-05-29 11:07 PM, Syd Bauman wrote:
Martin --
We'll talk tomorrow, I'm sure, but I'm not sure this is OK. I know you hate default values, as do I, and we want to get rid of them. But I'm not sure it's acceptable to yank them out w/o warning. DTD users might be upset. Besides, changing the semantics of a value like that is the sort of thing users need warning about. Those who actually have part="N" explicitly expressed may well be using it to say "I can't tell if this is a fragment or not".
MH> att.fragmentable's @part now has no defaultVal, and the "N" value MH> now actually means "no", as it should. Rev 13232.