Make @source global

[TEITechnicalCouncil]

Given that att.responsibility is becoming global (see [feature-requests:#443]), @source should also become global, since they belong together. See also [feature-requests:#465].

Original comment by: @hcayless

[TEITechnicalCouncil]

• assigned_to: James Cummings

Original comment by: @jamescummings

[TEITechnicalCouncil]

At Raleigh F2F: Assigning to myself to liaise with HC and see if we can agree at all. ;-)

Original comment by: @jamescummings

[TEITechnicalCouncil]

There are three types of @source attribute currently:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.readFrom.html#tei_att.source

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.source.html#tei_att.source

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-normalization.html#tei_att.source

These are all related in some way (giving the source of something) but are significantly different from each other that making @source global should be treated with care. Presumably global @source would replace all 3 of these types of @source.

Original comment by: @jamescummings

[TEITechnicalCouncil]

This issue was originally assigned to SF user: jcummings
Current user is: jamescummings

[jamescummings]

The basis of my argument for not making @source global is a general reluctance to add more things that are available everywhere. There seem to be a lot of elements for which I can't envision what a @source attribute means on it. I can see an argument for having it within textual transcription and with some bibliographic metadata, etc.

[hcayless]

My own contention is that there is almost nowhere that @resp can be used where @source does not also make sense. That said, I never thought @resp should be global either...

On Oct 27, 2015, at 13:40 , James Cummings notifications@github.com wrote:

The basis of my argument for not making @source global is a general reluctance to add more things that are available everywhere. There seem to be a lot of elements for which I can't envision what a @source attribute means on it. I can see an argument for having it within textual transcription and with some bibliographic metadata, etc.

—
Reply to this email directly or view it on GitHub #536 (comment).

[jamescummings]

Does that mean because we made one bad decision (well not one...) we should make another for parallelism? Still not convinced. ;-)

[hcayless]

Tell me where @resp makes sense and @source doesn’t then :-)

On Oct 27, 2015, at 23:39 , James Cummings notifications@github.com wrote:

Does that mean because we made one bad decision (well not one...) we should make another for parallelism? Still not convinced. ;-)

—
Reply to this email directly or view it on GitHub #536 (comment).

[jamescummings]

That's not my point. I'm saying I don't want @source where @resp doesn't make sense either. ;-) But ok, what about <revisionDesc> or <rendition>? I can technically think that <rendition> might have a @resp (I think it is stupid to do so, but whatever), but don't think it should have a @source. I was against @resp being global and I'm also against @source being global. I feel it leads to a pollution of the TEI to have more things unnecessarily global. ;-)

[hcayless]

That’s easy:

(i.e., I got my revision list from looking at the project commit logs).

I do sympathize, but @resp and @source go hand in glove. Now, @cert on is really batshit crazy. I suppose @cert="low" on might mean "I don’t know what the Hell I’m doing; I don’t actually know CSS, so I made something up." I can’t make much sense of it.

On Oct 27, 2015, at 23:46 , James Cummings notifications@github.com wrote:

That's not my point. I'm saying I don't want @source where @resp doesn't make sense either. ;-) But ok, what about or ? I can technically think that might have a @resp (I think it is stupid to do so, but whatever), but don't think it should have a @source. I was against @resp being global and I'm also against @source being global. I feel it leads to a pollution of the TEI to have more things unnecessarily global. ;-)

—
Reply to this email directly or view it on GitHub #536 (comment).

[martindholmes]

Whenever someone says something is batshit crazy my devious mind instantly thinks of a case where it might happen. Let's say your source doc no longer exists, and you only have a couple of bad transcriptions by ancient scholars. Those are also damaged. You're trying to infer the original rendition of the text from the inadequate representations made by the transcribers; and in one case they seem in conflict, with one more likely than the other. Surely @resp, @source and @cert?

Cheers,
Martin

Martin Holmes
UVic Humanities Computing and Media Centre
mholmes@uvic.ca

---

From: Hugh A. Cayless notifications@github.com
Sent: October 27, 2015 3:57 PM
To: TEIC/TEI
Subject: Re: [TEI] Make @source global (#536)

That's easy:

(i.e., I got my revision list from looking at the project commit logs).

I do sympathize, but @resp and @source go hand in glove. Now, @cert on is really batshit crazy. I suppose @cert="low" on might mean "I don't know what the Hell I'm doing; I don't actually know CSS, so I made something up." I can't make much sense of it.

On Oct 27, 2015, at 23:46 , James Cummings notifications@github.com wrote:

That's not my point. I'm saying I don't want @source where @resp doesn't make sense either. ;-) But ok, what about or ? I can technically think that might have a @resp (I think it is stupid to do so, but whatever), but don't think it should have a @source. I was against @resp being global and I'm also against @source being global. I feel it leads to a pollution of the TEI to have more things unnecessarily global. ;-)

Reply to this email directly or view it on GitHub #536 (comment).

Reply to this email directly or view it on GitHubhttps://github.com//issues/536#issuecomment-151669256.

[martindholmes]

Council 2015-10-28: A majority agrees to go ahead with adding @source to att.global.responsibility. Set to green. Left with James to implement.

[jamescummings]

I'm finally starting to look at implementing this. @lb42: Presumably, this should be waiting until Pure ODD is signed sealed and delivered since I'll need to modify so many spec files? I'll do it in a new branch off that when that has been added to dev.

Just to run it by people first what I think I need to do is:

1. add @source to att.global.responsibility with a datatype of data.pointer, one to infinity, and with a note and example(s). Its definition should merge and generalise the 3 uses of it in the guidelines.
2. delete att.readFrom since it only provides @source. Perhaps moving its note somewhere? (Suggestions? http://jenkins.tei-c.org/job/TEIP5/lastSuccessfulBuild/artifact/P5/release/doc/tei-p5-doc/en/html/USE.html#IM-unified ?)
3. remove XInclude of att.readFrom from https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/ST-Infrastructure.xml#L899
4. remove class membership of att.readFrom from classRef elementRef macroRef moduleRef schemaSpec
5. remove att.source since it only provides @source, using its examples in att.global.responsibility.
6. remove XInclude of att.source from https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/CO-CoreElements.xml#L1043
7. remove class membership of att.source from att.editLike [att.transcriptional [add addSpan del delSpan mod redo restore retrace subst substJoin undo] affiliation age am birth climate corr date death education event ex expan faith floruit gap geogFeat geogName langKnowledge langKnown location name nationality occupation offset org orgName origDate origPlace origin persName person place placeName population reg relation residence secl sex socecStatus state supplied surplus terrain time trait unclear] att.interpLike [interp interpGrp span spanGrp] att.textCritical [lem rdg rdgGrp] abbr abstract egXML handShift note orig provenance q quote respons rs seg sic space witDetail writing
8. remove @source from https://github.com/TEIC/TEI/blob/dev/P5/Source/Specs/normalization.xml#L37
9. Go through and remove references to att.readFrom, att.source, and discussion of the source attribute generally throughout the Guidelines prose and examples (e.g. of customisation). There are loads of mentions of these in a number of chapters... some examples include: https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/TD-DocumentationElements.xml#L309 https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/PH-PrimarySources.xml#L725 https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/CO-CoreElements.xml#L757 https://github.com/TEIC/TEI/blob/dev/P5/Source/Guidelines/en/ND-NamesDates.xml#L991 http://jenkins.tei-c.org/job/TEIP5/lastSuccessfulBuild/artifact/P5/release/doc/tei-p5-doc/en/html/USE.html#MDMDAL
10. update prose on att.global.responsibility to mention @source
11. Note that many tests (TEI and Stylesheets) will fail whose expected results depend on the existence of att.source and get someone else to fix those.

Anything major I'm forgetting there?

-James

[raffazizzi]

2. Adding the note to the Guidelines prose makes sense, but it's pity to lose it from the reference tables. Maybe we can add the note to the member elements (classRef elementRef macroRef moduleRef schemaSpec)?

[jamescummings]

@raffazizzi: That makes sense.

On Council list @lb42 suggests instead renaming the att.source class to att.global.source and change all mentions to be that. This might be less disruptive in terms of breaking things I think I'd still have to do most of the things above (though in some cases renaming to att.global.source). He also confirms this should wait until Pure ODD is finished.

[jamescummings]

Adding Status: Blocked until Pure ODD released.

[lb42]

Actually, no, that is NOT what I suggested. I suggested just adding the existing att.source class to att.global, and leaving the renaming to a later date[1]. After all, it's purely conventional that all subclasses of att.global begin with that string). This would be much less disruptive.

[1] by when common sense may have prevailed, and we may wish to deglobalise the wretched thing anyway

[jamescummings]

@lb42: Apologies. I misunderstood. However, I'm uncomfortable with breaking with convention for our class naming (that way anarchy lies). But even if the class name was the same wouldn't we still have to delete reference to it everywhere since those elements already are members of att.global and so would get it twice?

Once something has be globalised, and released to the public, I think it is bad form to deglobalise it without using proper deprecation, etc. This is one of those reasons I'm always so dead set against making thing global, much more dangerous to change or remove later IMHO.

[lb42]

Ah, yes. Bother. Thought it was too good to be true.

[martindholmes]

Ignoring the issue of whether it ought to be global or not, I don't think it's a good idea to create a global class which is uniquely excluded from the naming convention that helps people understand what's global and what isn't.

[sydb]

James —
Process you outline looks good at first glance, but of course (as you know), it is impossible to be confident in it w/o trying it. The only thing that jumps to mind that is missing is a step 9.5, as it were: check the Exemplars/*.odd files for references to att.readFrom and att.source.

[jamescummings]

Temporarily removing Status:Go to make sure I've got this right:

I'll do as I outlined above but:

• adding the att.readFrom note to current member elements.
• creating att.global.source rather than adding this to att.global.responsibility
• also checking through Exemplars/*.odd for references to att.readFrom and att.source

Just double checking before returning to status:go.

Right? (will assume no comments is agreement, but would be good to get some confirmation since this is a att.global.* change)

[ebeshero]

Council subgroup thinks this is a GREEN, and work on a branch.
(And is not expressing an opinion on use of att.global.source or tucking it into att.global.responsibility)

[jamescummings]

I'll go ahead and implement then.

[gabrielbodard]

Rather confused by the arguments above that adding @source to att.global.responsibility would be adding a further bad decision to an earlier bad decision. I think there are two (or maybe three) separate questions here, and you seem to be confusing them (or answering them in the wrong order):

1. Should @resp and @source always and only be available where the other is available. Undoubtedly yes. I have seen no arguments and no examples of elements where one is necessary and the other would be extraneous. @jamescummings even sidestepped this question above rather than attempting to disagree with it. Ergo, add @source to att.responsibility or some other new class.
2. Should att.responsibility (or the new class) be global? Maybe not. Council have already decided on (and implemented?) that. Maybe they were wrong. Maybe they should change their mind. Maybe breaking backward compatibility on something that was only introduced a few months ago isn't that big of a problem. (Maybe if breaking backward compatibility on that would actually hurt anyone, that's a sign that it wasn't a wrong decision in the first place. :-p )
3. Which would be worse: (a) incorrectly decoupling @resp and @source when they are attributes that complement each other, sometimes as alternatives, sometimes taken together, or (b) incorrectly making @source global rather than damn-near-global-but-not-quite? In my view, a. breaks the functionality, rationality and usability of the TEI in specific and serious ways; b. upsets a few people's opinions about the purity of the content model. I like to avoid the latter where possible. But the former leads to a recommendation that is b r o k e n .

Is the alternative that a feature request should be opened for every element on which we need @source where it isn't currently available? For starters I need it alongside @resp on <div>, on <head>, on <p>, on <ab> and on <lg> and <l> (for citing bibliographic origins of quoted translations of texts or parts of texts); and on <physDesc>, <layoutDesc>, <layout>, <history>, <handDesc>, <handNote>, <dimensions> etc. (for citing bibliographic origins of elements of object history and description). Shall I go on?

[martindholmes]

Making @resp global was a good decision, and has been instantly useful for us (and for the many other people who supported the ticket, and asked for it on the list). If Council were to decide to reverse a decision with such strong support after implementation, breaking backward compatibility, I'd lose all confidence in the whole project, personally.

I don't really have an opinion on @source because I typically don't use them together; we use the global @resp to point from all sorts of elements to <respStmt>s in the header which explain the exact nature of the responsibility using a standard taxonomy combined with textual description. But if you convince me that wherever @resp should be available, so should @source, then global it should be. There's nothing wrong with global attributes; we have lots of them. If people don't want them they can remove them from their schemas.

[gabrielbodard]

To be clear, I'm not really arguing for reversing that decision (I didn't have a strong opinion on it either way to start with, but I tend to agree with you that there's nothing wrong with global attributes or classes), rather I was pointing out the irrationality of using resentment of the globality of @resp to resist adding @source to att.responsibility.

I think I may have trouble making clear the complete parallelism and interdependence of @resp and @source because it is so self-evident to me. (It might be easier over a beer, or with a scratchpad between us.)

If @resp "indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber", i.e. the person or other entity who has made a decision, applied markup, proposed an emendation, etc., then as you say it's hard to think of any element that could not use this attribute. But by the same token, any element that you might want to record the person immediately responsible for making a decision about the content of, you might also want to record a published or other source that is the origin of the content or decision being recorded. I contend, in other words, that anywhere you might want to say,

1. Person #gbodard is responsible for this tagging or content

You might also want to say either or both of:

1. This tagging or content is taken from the published source #holmes2012
2. (More rarely) person #gbodard is responsible for this tagging or content, taken from (his interpretation of) #holmes2012

Even if, as is clearly the case, you might not always want to be able to make all three of these statements, the fact that the two attributes belong together—conceptually as well as technically—is unchanged. They might need to be used, separately or together, in almost any context. (Most of us will never use @resp on most elements, but it is still available everywhere.)

[jamescummings]

I'm not quite sure how I've sidestepped anything. I was suggesting that I was going to do this by creating att.global.source rather than putting it into att.global.responsibility -- both of these are global classes. The issue is agreed and Council says I should go ahead with this. (I've just been busy with other things but will do so before next release.) I was just double-checking the steps that should be taken since I'd rather not muck it up. (Hence Council's suggestion to work in a branch.) The issue here is now only waiting on my implementation of it to close, unless you have a variation on how I should be implementing it?

I do disagree that there isn't anything wrong with global attributes (or classes) -- because these are global and thus appear anywhere I think there should always be a higher bar to accepting them because more and more global attributes seems to ben an entropic direction of travel. (We then get asked, why not make all attributes global, all elements allowed everywhere, etc.) I think as elected representatives of the community we should definitely play devil's advocate any time anyone suggests additional elements or attributes that can appear anywhere. This doesn't mean I'm against them, just that we should do our due diligence in ensure the argument for them is made. However, I don't really think individual issues is the right place to discuss this. (And I probably owe you a beer in any case....) In this case, while I personally have my reservations, I'm instructed to add it, and so will do so. (Soon'ish, I promise.)

[gabrielbodard]

Ah, okay! I'm delighted then to say that I misunderstood the status of this ticket (I asked a council member—who shall remain unnamed—why @source wasn't yet available alongside @resp and was pointed to this ticket to argue for it), and to apologise for mischaracterising your position. (The side-stepping I crassly mentioned was in the conversation with hcayless near the top of this page. * )

I still don't understand why @resp and @source should not be in a single class, for convenience and security, but so long as they're both available everywhere I need them, I'll not trouble myself with the internal technicalities of the TEI. ;-)

Thanks!

[hcayless]

Should all be dealt with now.