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.
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
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
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
participants (4)
-
Bauman, Syd -
Elisa Beshero-Bondar -
Janelle Jenstad -
Martin Holmes