#458 Make listBibl and model.biblLike member of model.personPart

AMBER
closed
nobody
None
1(low)
2014-08-13
2013-06-04
Laurent Romary
No

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

Related

Feature Requests: #458

Discussion

  • 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

     
  • Lou Burnard
    Lou Burnard
    2013-06-04

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

    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/

     

    Related

    Feature Requests: #458

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

     
  • Laurent Romary
    Laurent Romary
    2013-06-04

    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.

     
  • Lou Burnard
    Lou Burnard
    2013-06-18

    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.

     
  • Martin Holmes
    Martin Holmes
    2013-06-18

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

     
  • Lou Burnard
    Lou Burnard
    2013-06-18

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

     
  • Kevin Hawkins
    Kevin Hawkins
    2013-11-11

    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
  • Lou Burnard
    Lou Burnard
    2013-11-12

    • status: open --> closed
    • Priority: 5 --> 1(low)
     
  • Lou Burnard
    Lou Burnard
    2013-11-12

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