Missing Plays

> I'm ok (and prefer) having multiple flags, like EXCEPTION_99_CD,
> EXCEPTION_#_CD, etc (though # may be illegal in a field name). I was
> offering my suggestion in case you didn't want to have multiple exception
> type fields.

I don't mind a proliferation of fields for good cause. Filling in the
"gaps" BEVENT leaves in Retrosheet process because of developments that
occurred after the 97 columns were enshrined is a good cause.

How about giving these more descriptive names, though. The user also
shouldn't have to immediately know what "99" or "# means. How about

EXCEPTION_UNKNOWN_OUT_CD
EXCEPTION_UNCERTAIN_PLAY_CD

Or some suitable abbreviation, if those are too long. This would also
accommodate the possibility that somewhere down the road, Dave will be
willing to entertain a more formal extension to the notation to capture
uncertainty about events.

>
>
> The reason against the parsing is that the user would have to know about
> "99" and "#". I'm a power user, and the first I heard about it was a few
> weeks ago. I would guess 99% of users wouldn't even think to look for it.
> Would anyone know that a "generic out" is not always an out? I could go
> on.
>
> Our motto should be: "We parse, so you don't have to."
>

I don't really consider substring-checking to be "parsing." But, by the
same token (and my argument above), users shouldn't have to know how unknown
or uncertain events are coded.

BTW, there is (or used to be) a "missing play" event type documented in
BEVENT -- plays now coded 99 once were supposed to be coded MP.BX1(?) or
some such. But I like instead calling these "generic outs" (because they
almost surely are batted ball outs -- heck, wouldn't "batted ball out" be a
much better name than "generic"?) but flagging them as "fielding credit
unknown" or "play code uncertain."

If you're happy with this idea or some marginal tweak on it, please stick it
in the feature requests tracker on sourceforge for me.

Ted