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
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