[tei-council] "soft deprecation": use @status='deprecated' ?

[Gabriel Bodard]

That's a good point. I do something very similar to C with the EpiDoc 
ODD/schema. (Attribute values that we no longer recommend and plan to 
take out of the valList in a future release have the word "DEPRECATED" 
and a brief explanation of what you should use instead at the start of 
their desc.)

Remember that, at least with current technologies, most people don't see 
the schematron validation errors/warnings if they only have a 
xml-model[@schematypens='rng'] in their document.

G

On 2013-01-14 11:43, James Cummings wrote:
>
> I think I'm with Lou and partly with Gabby here.
>
> When something is deprecated, it is deprecated. It should get a
> little red warning on the reference page. And it would be even
> better if there was a date attached so it could say 'To be
> removed at the release following 2014-01-13' or something.  IF
> our user community read the reference pages regularly then I
> think that is where it should end.  However, I think it much more
> likely that they use the schemas in oxygen, start putting in an
> element and if it is allowed then it is allowed.  Thus schematron
> warning rules and a change to the description might be beneficial.
>
> I see the following options on deprecation:
>
> A) Marked as deprecated on the reference page preferably with a
> note with date or similar at which it will be removed.
>
> B) Marked as deprecated on the reference page preferably with a
> note with date or similar at which it will be removed, and a
> schematron warning rule set up.
>
> C) Marked as deprecated on the reference page preferably with a
> note with date or similar at which it will be removed, a
> schematron warning rule set up, and the <desc> changed to be
> prefixed with 'DEPRECATED: '.
>
> Changing the <desc> will result in people noticing this in
> tooltips in software like oXygen, make it that much more evident
> on the reference page, and where specDesc has been used to pull
> in the description elsewhere.
>
> Of these I'd prefer that we are the clearest we can possibly be,
> and so would vote for C.
>
> -James
>
> On 14/01/13 11:27, Gabriel Bodard wrote:
>> I never use warnings in my Schematron, primarily because they're
>> annoying. If something is disrecommended rather than incorrect, then
>> presumably that means it's sometimes right, and I don't want to get a
>> validation error (even if it is a less "wrong" color) every time it
>> occurs. I don't know any validator that doesn't say "errors found" when
>> schematron issues warnings.
>>
>> That said, I think the value of deprecation is precisely that people can
>> carry on using the deprecated attribute (vel sim) without having to
>> think about it especially, just receiving a gentle warning (in the
>> Guidelines, I guess) rather than that people have to speifically
>> re-introduce a deprecation module to their schema to keep the attribute
>> around. In general people who want to be this proactive with their
>> schemas are the ones who will take account of deprecation the soonest.
>>
>> tl;dr I vote for the red "Deprecated" flag in the element/class Spec page.
>>
>> Gabby
>>
>> On 2013-01-14 09:43, Sebastian Rahtz wrote:
>>>
>>> On 13 Jan 2013, at 23:57, Martin Holmes <mholmes at uvic.ca>
>>>     wrote:
>>>
>>>>> Does Schematron formally support Warnings as opposed to Errors?
>>>>
>>>> I use them in my Schematron and they certainly work in Oxygen. You just
>>>> get a yellow icon instead of a red one in your validation results at the
>>>> bottom of the screen.
>>>>
>>> sounds like we should use this immediately to indicate deprecation?
>>>
>>> --
>>> Sebastian Rahtz
>>> Director (Research Support) of Academic IT Services
>>> University of Oxford IT Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>
>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/