I agree that this does not need deprecation, because we are simply making sure the schema supports what we show in the Guidelines. That said, I wish we were recording this discussion on the ticket for logging our work. I don’t think it is at all controversial, just noting that conversations on the ticket are a way of connecting with our community, or at least those in it who follow our GitHub activity. I’d recommend linking to this Council discussion in our email list archive, and mark this Green to proceed.

Elisa

Elisa Beshero-Bondar, PhD
Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities |  Director of the Digital Humanities Lab at Penn State Erie, The Behrend College 

Typeset by hand on my iPhone

On Jan 19, 2021, at 2:13 PM, Janelle Jenstad <jenstad@uvic.ca> wrote:

Hi Syd,

New council member says "thanks for the full explanation."

It doesn't sound as if deprecation is needed, so I'm agreeing with you, Martin, and Magdalena.

J.

Janelle Jenstad, Associate Professor, Department of English, University of Victoria
Director, Map of Early Modern London; Director, Linked Early Modern Drama Online
Coordinating Platform Editor, Digital Renaissance Editions
Email: jenstad@uvic.ca, lemdo@uvic.ca, or london@uvic.ca


-----Original Message-----
From: Tei-council <tei-council-bounces@lists.tei-c.org> On Behalf Of Martin Holmes
Sent: January 18, 2021 7:30 AM
To: tei-council@lists.tei-c.org
Subject: Re: [Tei-council] shift of validation need deprecation?

Notice: This message was sent from outside the University of Victoria email system but is claiming to be from UVic. Please be cautious with links, attachments, and sensitive information.


Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.


Hi Syd,

I'm with you and Magdalena on this one. I don't think there will be [m]any instances in the wild of actively-maintained and -used TEI files containing <specDesc> without @key.

Cheers,
Martin

On 2021-01-18 5:14 a.m., Bauman, Syd wrote:
I am hoping to close several tickets, including #2062
<https://github.com/TEIC/TEI/issues/2062> very soon. This one “needs
discussion”, IMHO, only on the issue of whether or not deprecation is
required. Could folks weigh in on the ticket, please?

Issue: the @key attribute of <specDesc> is optional in the schema, but
required by the Stylesheets. The request is to require it in the
schema, too.

Decision (unilateral, by me): yes, we should make @key of <specDesc>
required by the schema.

Question: Do we have to provide deprecation for this change?

Discussion 1: The <specDesc> element “indicates that a description of
the specified element or class should be included at this point within
a document”. The @key attribute is the only mechanism by which the
element or class you want to be included can be indicated. Therefore a
<specDesc> without a @key is not doing what it is supposed to do.
Currently, a <specDesc> without a @key passes validation, but then
when processed by the Stylesheets the message “ERROR: no key attribute
on specDesc” is generated (by Stylesheets/common/common_tagdocs.xsl);
processing continues, and the spot where the @keyless <specDesc>
occurred is simply blank in the output HTML.

Discussion 2: We have decided in the past that, in general, changes
that break backward compatibility should be deprecated. (I.e., users
should get a warning, not an error, for 6 months to 2 years before the
feature is changed to an error.)

My opinion (on the question “Do we have to provide deprecation for
this
change?”): Emphatically not, this is a corrigible error. The change
only effects /when/ the user gets an error message, not /if./ One of
the main reasons to have schema validation is to catch errors before
you get to the processing stage.

Discussion 3: One (especially a new member of Council) may well ask,
why did I even bother raising this question? The answer is an
abundance of caution. The question of whether or not a change need be
deprecated is often an issue with disagreement within Council. I have
a (well
deserved) reputation for having a high threshold for requiring
deprecation; others (including Peter and Martin) have a reputation for
a much lower threshold. Thus it makes sense to make sure that I am not
the only one who thinks this does not need deprecation.

_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council


--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
mholmes@uvic.ca
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council