[tei-council] validUntil deprecated, so says Schematron

[Syd Bauman]

Thank you, Sebastian.

> ... run locally, which generates a different ValidatorLog.xml, so
> this line now fails. 

Not quite. The Makefile tests ValidatoLog.xml for the presense of
"<ERROR>", and fails before it does the diff. In order to fix this,
it seems to me we need to update Utilities/validator.xsl so that it
knows about the role= attribute on <report> as well as <assert>. 

But while I'm at it, this routine could stand several other
improvements. Is its output used anywhere else, or can I make
improvements without much concern? (Only has to match
expected-results/, so not a big deal.)


> Now copy your ValidatorLog.xml file to
> expected-results (if you’re happy its correct) and commit that
> change. next time around, d.v. the test succeeds

(What does "d.v." mean?) 
This means that we have to change ValidatorLog.xml every time we
add or change a validUntil=. Do we like that result? Or would we be
happier teaching the build process to ignore this whole class of
error messages?


> you’ll have spotted that the checking is quite contorted ...

Indeed. :-)


> > But what about a model class? Certainly @validUntil on a model
> > class does not mean that the elements that are members of that
> > class are deprecated. But what about elements that refer to said
> > class in their content models? *They're* not deprecated, for
> > sure. I lean towards saying that what is deprecated here, if
> > anything, is occurrences of members of the class in elements that
> > refer to said class.
> 
> seems to me that this just doesn’t supply to instance texts. its s
> sublety for ODD writers.
> > ...
> I feel that you won’t get anywhere useful with this. it will entirely
> baffle the user...

So, unless there's an uproar "I want to deprecate model classes and
have users warned when instances in which such elements are used are
validated, darn it!", I'm going to ignore model classes.


> > Flagging a <schemaSpec> with
> > validUntil= seems so weird, I'm not sure it makes sense.
> 
> I agree :-}

See below.


> > Why is <valDesc> a member of att.deprecated, but <desc> is not?
> > What about <gloss>, <defaultVal>, <exemplum>, or <remarks>?
> 
> i really don’t see how we can talk about deprecation of
> documentation, so I’d imagine <valDesc> would come out of the class.

I'm going to submit a bug report to tweak the membership of
at.deprecated.
* remove <schemaSpec> and <valDesc>: pretty obvious, I think
* remove <constraintSpec> and <macroSpec>: perhaps contentious?