Sorry, Martin, I simply disagree. [But to be clear up front: I'm still against default values in schemas and think we should get rid of them. That does *not* mean necessarily mean I think we should get rid of <defaultVal>, however.] First, to be sure, even if I agree it (@part and its default value) is broken as designed, it has been broken in exactly that way since at least P2. To rush to repair because "we can't possibly allow the situation as it [is] to continue" is silly. We (writ large) have allowed it to continue for well over 2 decades. But more importantly, it's a change that simply requires us to go through a deprecation process and warn users ahead of time. It breaks backwards compatibility. Yes, I agree, I don't think there is anyone out there using it in a way that will be adversely affected, but I think the reason we have Birnbaum principles is in small part because it's not for us to say. You were charged with making a list of attributes that make use of <defaultVal> so that we could examine them and decide what to do next, not with hacking them out of P5 (at least, not yet). Control your anger, master Jedi, lest you be turned like a Padawan who has lost sight of Birnbaum.

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.

Martin, is this some sort of trick? That page only has 2 instances of <defaultVal> listed, but there are roughly 65 of them. I most certainly do *not* want to move forward with these one at a time. I want to see and analyze a list of all of them. My bet is that, upon seeing said list, I am going to push for leaving <defaultVal> in, but changing its semantics so that the default value is not actually tucked into DTDs and schemas, but rather <defaultVal> is a hint for your TEI processor. After we've changed those semantics (which will take a year or whatever), I would then be happy to see <defaultVal> all over the place. And whether we should split the meanings of part=N into two separate values or not is a somewhat different question. (One which I would support wholeheartedly. That said, the current situation is not nearly so crazy as you make it out to be -- part=N indicates to your hunter/gatherer software which you use to reconstitute partial elements into aggregate elements that it does not have to pay attention to this particular element instance. It does not assert *why* your software can ignore it, which is a pity. But it's not useless in a default attr value environment.) P.S. And of course the default value of org= is "uniform" ... how many times have you even considered specifying org=composite?

OK, page is up on the wiki:

http://wiki.tei-c.org/index.php/DefaultVal_candidates_for_removal

I'd like to move forward with these steadily, though, otherwise there'll just be a long page left on the wiki when I leave Council and nothing will be done, so I'd like ask for any objections to the first two actually to be recorded on the wiki.

I thought I was tasked with analyzing each one and suggesting an action for it.

That's close to my understanding, too. I just think by "each" we mean "all at once". I.e., I was expecting a list of table of all <defaultVal> elements with your suggested disposition. (And for most, if not all, I expect your suggested disposition to boil down to "kill it". :-) But I'm happy to do that; you're right, it at least was my ticket. :-)

If not, then I'm inclined to let you proceed with the ticket the way you want to, since you're the owner.

...

I most certainly do *not* want to move forward with these one at a time. I want to see and analyze a list of all of them. My bet is that, upon seeing said list, I am going to push for leaving <defaultVal> in, but changing its semantics so that the default value is not actually tucked into DTDs and schemas, but rather <defaultVal> is a hint for your TEI processor.

That seems like a completely new idea to me, not related to my original ticket. But it seems to me that if you're wanting to provide hints to a processor, the place to do that is in the PM, not in the schema specification.

Are we talking about the same ticket? It was submitted by Lou, and in the OP he suggests making this information semantic rather than actionable; and Sebastian, in the first comment, suggests making <defaultVal> into a machine-readable bit of information for humans, rather than an actual schema default. (I.e., a processor hint rather than a schema requirement.) [I'm going to skip a bit here and respond only to last point right now ...]

My point is that "uniform" is also a claim, and we shouldn't be having people make claims that they don't know about. Maybe I don't care whether my divs are composite or uniform -- why is a claim that they're uniform foisted on me without my knowledge? As we keep saying, it's magic and it's misleading.

Yes it's a claim, a claim that you make with 99.9% of the elements you ever encode. Can you imagine what would happen if that were *not* the assertion you were making? <lg> <l>And it's worth it just to hear you say you're going to give me everything</l> <l>But when I get home to you I find the things that you do</l> <l>But when I get home to you I find the things that you do</l> <l>But when I get home to you I find the things that you do</l> <l>It's been a hard day's night, I should be sleeping like a log</l> <l>It's been a hard day's night, I should be sleeping like a log</l> <l>It's been a hard day's night, I should be sleeping like a log</l> <l>It's been a hard day's night, and I been working like a dog</l> <l>It's been a hard day's night, and I been working like a dog</l> <l>It's been a hard day's night, and I been working like a dog</l> <l>So why on earth should I moan, 'cause when I get you alone</l> <l>So why on earth should I moan, 'cause when I get you alone</l> <l>When I'm home everything seems to be right</l> <l>When I'm home everything seems to be right</l> <l>When I'm home feeling you holding me tight, tight</l> <l>When I'm home feeling you holding me tight, tight</l> <l>Will make me feel alright, oww</l> <l>Will make me feel alright</l> <l>Will make me feel alright</l> <l>You know I feel OK</l> <l>You know I feel OK</l> <l>You know I feel alright</l> <l>You know I feel alright</l> <l>You know I work all day to get you money to buy you things</l> </lg> (Tommie Usdin made this very point in an opening keynote address at Extreme Markup Languages years ago.) P.S. for everyone else: Martin & I discussed covers at dinner in Ann Arbor, and I told him I thought Peggy Lee's cover of the above song, in proper order and a few clever tweaks, is *marvelous*: https://www.youtube.com/watch?v=mUBAGLinKfI