Menu
▾
▴
#458 Make listBibl and model.biblLike member of model.personPart
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...
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
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:
Related
Feature Requests:
#458true, 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.
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.
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.
(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?
(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.
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.
Last edit: Kevin Hawkins 2013-11-12
Council agreed to downplay Martin's concern and close the ticket.