Make listBibl and model.biblLike member of model.personPart

[raffazizzi]

Quite surprisingly [bibl] appears as the only member of model.personPart I have the typical case at hand of a dictionary of authors, which I encode with [person] and which for entry contains a list of bibliographical references where the author is mentioned. I thus need [listBibl] there but think it would be the opportunity to generalise also from [bibl] to model.model.biblLike as member of model.personPart PS: and it is so annoying that you cannot use < for elements in this version of sourceForge...

Original comment by: laurentromary

[raffazizzi]

I agree with you, this is really quite a strange omission. I see no reason why we would not have model.biblLike in place of raw <bibl>

You have to put literal XML inside backquotes here, by the way

Original comment by: sebastianrahtz

[raffazizzi]

There are two propositions in this FR -- One is to make model.biblLike a subclass of model.personPart ; the other is to add [listBibl] to the same class.

Which one are you (Sebastian) agreeing with? both? I have no problem with adding [listBibl] to the class and removing [bibl], though it does mean some additional tagging in the case where you have only one [bibl]; I feel vaguely uncertain about allowing both [listBibl] and [bibl] at the same level.

PS. would it be less annoying to use a convention such as square brackets instead?

On 04/06/13 08:40, Sebastian Rahtz wrote:

I agree with you, this is really quite a strange omission. I see no reason why we would not have model.biblLike in place of raw ||

You have to put literal XML inside backquotes here, by the way

---

[feature-requests:#458] http://sourceforge.net/p/tei/feature-requests/458/ Make listBibl and model.biblLike member of model.personPart

Status: open Created: Tue Jun 04, 2013 06:59 AM UTC by Laurent Romary Last Updated: Tue Jun 04, 2013 06:59 AM UTC Owner: nobody

Quite surprisingly [bibl] appears as the only member of model.personPart I have the typical case at hand of a dictionary of authors, which I encode with [person] and which for entry contains a list of bibliographical references where the author is mentioned. I thus need [listBibl] there but think it would be the opportunity to generalise also from [bibl] to model.model.biblLike as member of model.personPart PS: and it is so annoying that you cannot use < for elements in this version of sourceForge...

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/458/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Original comment by: lb42

[raffazizzi]

true, Lou, I wasn't thinking. I would start with agreeing that listBibl should be allowed inside <person>. How to achieve that? a) explicitly allow <listBibl> alongside <bibl> b) change to model.biblLike (and thus get biblStruct etc) and add listBibl to model.biblLike c) allow model.listLike inside <person>

I am torn between a) and b). The idea of bibl alongside listBibl doesn't bother me too much.

Original comment by: sebastianrahtz

[raffazizzi]

I had not thought of it, but I do like b) listBibl is a kind of alternative to normal bibl* things when you want to group them together (exactly my current use case, where I would not want to loose simple bibliographic references.

Original comment by: laurentromary

[raffazizzi]

I conclude that (a) model.biblLike should be a member of model.personPart (b) listBibl should become a member of model.biblLike (c) to avoid ambiguity in the definition of model.inter, listBibl also needs to be removed from model.listLike (d) bibl should be removed as a member of model.personPart (e) For consistency, remove bibl biblStruct and listBibl as explicit members of model.msItemPart, and made model.biblLike a member of that too.

Original comment by: lb42

[raffazizzi]

(c) seems very odd; listBibl is surely a list. Is there no other solution to the problem of model.inter? (d) will break backward compatibility, won't it?

Original comment by: martindholmes

[raffazizzi]

(d) doesnt break backwards compatibility: bibl still appears in personPart but via its membership of model.biblLike

Removing listBibl from model.listLike means that this class now contains only the listTrait etc things, which may help with another ticket. it would only be a problem if there were any model expecting to get listBibl via the class, but I don't see any.

Original comment by: lb42

[raffazizzi]

Breakout group at Council meeting notes that Lou has already done items (a), (b), (c), and (d) at revision 12279 on 2013-06-18, and it appears that (e) has been done as well. It appears that no one has addressed Martin's concern on (c). We see no obvious backwards-compatibility issues, so we are content for this ticket to be closed.

Original comment by: kshawkin

[raffazizzi]

• status: open --> closed
• Priority: 5 --> 1(low)

Original comment by: lb42

[raffazizzi]

Council agreed to downplay Martin's concern and close the ticket.

Original comment by: lb42