[tei-council] tricky situations for using @validUntil

[Syd Bauman]

> In the third solution ...
> ... do I understand correctly that instead of relying on the build
> process failing after the date specified in @validUntil to remind
> us to actually remove something, we would rely on someone using
> Schematron on some data involving the actual usage, noticing that
> the date has passed, and reporting to us that we are overdue in
> actually removing it? If so, that would be unfortunate. Would there
> be any way of making this warning message with the date
> machine-readable so that the build process could fail on this in
> the way that it fails with @validUntil as used elsewhere?

Well, yes and no. I had something a *little* more than relying on
someone to accidentally use the deprecated feature in an instance in
mind. I thought perhaps someone of us would actually remember, or
even write down on say, a calendar, that the feature was to be nuked.

So my idea for solution #3 was non-build-process methods of reminding
ourselves to take action on a certain date. That said, there probably
isn't any reason not to do something other than @validUntil to cause
the build process to deliberately fail after a certain date. But boy,
it then sounds a whole lot like the @errorAfter of solution #1.

I have to admit, I think I'm mildly partial to either @errorAfter as
an attribute or perhaps a PI. As an attribute it is just a flag to us
to make us change something before building works. That might make
sense in places where @validUntil doesn't make sense. However, it
might be better to use a PI, in that one can then
a) put the flag pretty much anywhere, and 
b) store additional helpful info. E.g.
     <?tei-council fatalDate 2017-12-01 featureRequest 812 
                   sometime before the 2018 Q1 build this class
                   should be renamed to "foo-bar". ?>
And, after all, it *is* an instruction to the processor (throw an
error).