XMLTV / xmltv

Utilities to obtain, generate, and post-process TV listings data in XMLTV format
GNU General Public License v2.0
275 stars 93 forks source link

DTD #134

Closed jpoet closed 2 years ago

jpoet commented 3 years ago

Is there any chance of DTD 0.6 becoming official anytime in the near future? At least as an option?

Alternatively, Can the role element be added to the current DTD?

<!-- role - details of a role played by an actor

     The name of the character is optional, if all you have is the actor's
     name.  The 'guest' attribute is used to distinguish guest stars from
     regular cast.
-->
<!ELEMENT role ((character, actor?) | actor)>
<!ELEMENT character (#PCDATA)>
<!ATTLIST character xml:lang CDATA #IMPLIED>
<!ELEMENT actor (#PCDATA)>
<!ATTLIST actor href  CDATA      #IMPLIED
                           guest (yes | no) #IMPLIED>
honir commented 3 years ago

Welcome to XMLTV Project.

The DTD aleady has role (as an attribute of actor). The "official" DTD is here https://github.com/XMLTV/xmltv/blob/master/xmltv.dtd

You do not say what software you are using. Maybe your question relates to a specific usage of XMLTV (e.g. MythTV)? In which case you need to ask on their forum.

But note that just because something is in the DTD does not mean that any data grabbers will actually support it - for example, I cannot think of any official current grabber which provides actor roles.

jpoet commented 3 years ago

Sorry I was not more specific.

I am using tv_grab_zz_sdjson_sqlite with MythTV. It does support role for actors. It does not support role for guest, though and the author says that is because the XMLTV DTD does not allow for it. DTD 0.6 allows for that but not the current DTD.

What is the current official way to propagate the role of a guest star?

Thank you,

John

garybuhrmaster commented 3 years ago

But note that just because something is in the DTD does not mean that any data grabbers will actually support it - for example, I cannot think of any official current grabber which provides actor roles.

By visual examination of the code, both tv_grab_zz_sdjson_sqlite and tv_grab_uk_tvguide can apparently provide actor roles if the data is available from their sources (and I know that tv_grab_zz_sdjson_sqlite does get actors and guest star roles from its upstream source often enough that it could have some value for some use cases).

rmeden commented 3 years ago

On 3/28/2021 9:59 AM, John Poet wrote:

I am using tv_grab_zz_sdjson_sqlite with MythTV. It does support role for actors. It does not support role for guest, though and the author says that is because the XMLTV DTD does not allow for it. DTD 0.6 allows for that but not the current DTD. Looks like it's already there

<!ELEMENT credits (director, actor, writer, adapter, producer,                    composer, editor, presenter, commentator,                    guest )> <!ELEMENT director    (#PCDATA)> <!ELEMENT actor       (#PCDATA)> <!ATTLIST actor role  CDATA #IMPLIED> <!ELEMENT writer      (#PCDATA)> <!ELEMENT adapter     (#PCDATA)> <!ELEMENT producer    (#PCDATA)> <!ELEMENT composer    (#PCDATA)> <!ELEMENT editor      (#PCDATA)> <!ELEMENT presenter   (#PCDATA)> <!ELEMENT commentator (#PCDATA)> <!ELEMENT guest       (#PCDATA)>

I checked to see what I do with in tv_grab_na_dd (Schedules Direct's older SD-DD feed). Looks like I process a Gracenote role of "Guest Star", but the The Late Show with Stephen Colbert reports the role as "Guest".  I suspect they changed it at some point.  I've updated tv_grab_na_dd, and tv_grab_zz_sdjson*  should also be able to do the same.

Robert

garybuhrmaster commented 3 years ago

Looks like it's already there

Not quite, the request is about providing a "role" for a guest star (actor). There is no separable definition of a guest star, and the guest element does not have a role attribute, and using the actor element for guest stars can result in different artifacts (if you are searching for all programs where [famous actor] is an actor, you may not want programs where s/he is only a guest star)

Per discussions at least half a decade ago (originally probably two decades ago, but I don't have that history), a "guest" is for talk show guests, not guest stars (actors), although there are likely other grabbers that use guest to mean guest star. So (for your example) guests on Stephen Colbert is a (talk show) guest, where [famous actor] on the TV show TBBT is (in Schedules Direct) likely be a Guest Star.

The 0.6 dtd proposal from the todo/ folder added the ability to support an attribute "guest" for an actor, which is, I think, what the OP wants to be able to differentiate.

rmeden commented 3 years ago

Good point! Looks like I've been doing it wrong in *na_dd all these years (decades?)! Gracenote does offer a "Guest" role (which I wasn't processing before) and a "Guest Star" role, which I was storing as Guest (I probably thought better than nothing at the time).

Adding attributes to roles is a pretty major change to the DTD. How about adding a "Guest Actor" or "Guest Star" role? I suspect most grabbers may currently use the Guest or Actor role, which was probably better than nothing. As I mentioned, that's how Gracenote does it ("Guest Star"), but I'm not sure if not calling them an Actor is a US thing.

jpoet commented 3 years ago

rmeden, adding "Guest Actor" or "Guest Star" is fine with me. That fits well with the current DTD organization.

garybuhrmaster commented 3 years ago

Adding attributes to roles is a pretty major change to the DTD.

Adding an additional attribute to the actor credit, or adding an additional credit element, are, arguably, the same scale and impact, but it is also something that should be expected to eventually happen as the data is enhanced (the dtd already says that the data may be enhanced in the future in various places).

FWIW, In this particular case, I think being a guest actor is better as an attribute (related, but different, to the 0.6 dtd proposal) as I suspect it is likely to parse better by some existing apps some of the time (if they ignore the attribute they still get the credit as actor in the program, where as if this is a new element as in "guest-actor", they might miss the person as an actor entirely until they are updated).  On the other hand, I do not feel strongly about whether this should be an attribute of the actor credit element, or a new guest-actor credit element.  FD: I am working against my own interests suggesting an attribute (as it is easier to modify my grabber for a new guest-actor element).

Regardless, I think some additional guidance for both grabbers and applications should be placed somewhere just to make sure that expectations are clear.  The points I think worth considering would include: While all applications processing the xmltv file SHOULD implement RFC 761, which states "be conservative in what you do, be liberal in what you accept from others." meaning that elements and attributes that are not recognized should be ignored (most xml parsers have an option to do so), the reality is that some apps are not always going to follow the recommendation and will either abort or complain about any additional element or attribute.  That leads to the follow-on guidance that grabbers that implement newer features SHOULD (should it be a MUST?) have the ability to configure whether newer elements and attributes will be emitted for a period of time (a few years for apps to adjust after the first xmltv release that incorporates the changes seems reasonable, although that might just delay the inevitable as the project has experienced that many people are running their grabbers and apps on auto-pilot and do not notice warnings about changes until things do not work).

The change (I am proposing) for the dtd would be something like changing the line:

<!ATTLIST actor role CDATA #IMPLIED>

to be

<!ATTLIST actor role   CDATA      #IMPLIED
                guest  (no | yes) #IMPLIED>

("yes" and "no" are the xmltv convention for other booleans in the dtd, and in this case if not specified the guest would be no?)

which could generate lines of the form:

<actor role="Jim" guest="yes">Name of Actor</actor>
rmeden commented 3 years ago

Gary, you raise a good point about actor + guest attribute falling to just actor rather than a new role for which an application may not display (most don't display producer for example). It would be interesting to get feedback from some data consumer apps. Many apps are old and no longer developed, so solutions that help them are good!

If I code this for *na_dd, I would probably display guests first (most important), as apps may only display the first X actors.

garybuhrmaster commented 3 years ago

If I code this for *na_dd, I would probably display guests first (most important), as apps may only display the first X actors.

I'll point out that for Schedules Direct (Gracenote) there is a billing order, and (at least for US guide data) my reading of the SAG-AFTRA rules(1) says that regulars get higher billing that guest_stars (of course, as with anything else, there are probably exceptions(1)), which seems to be consistent with the billing order provided.

I can see the logic in your proposal (guest stars first), but it may end up needing some adjustments (some guests stars may be minor, but again, SAG-AFTRA rules(1) may require them to be named in at least some cases (I think typically speaking parts, as background does not matter, although if the background actor is Anthony Hopkins he might be named if he requests it in his contract (or not, those are in the weeds of the SAG-AFTRA rules(1))).

My first reaction says use the Gracenote billing order (let those whose job is to insure the order is right specify the ordering), but that is just my first reaction.

(1) The SAG-AFTRA rules are long, and complex, and have subtleties. I am not an entertainment lawyer, and have no desire to go into that field, so my quick reading is almost certainly wrong in at least some parts.

jpoet commented 3 years ago

I will be the one adding support into MythTV. MythTV will show all of the actors and guest actors and the user can scroll if the list does not fit on the screen.

rmeden commented 3 years ago

@jpoet do you have a preference as to a "actor" attribute or separate role? What about wording? Guest Star or Guest Actor? (I'm not sure if Guest Star is US centric)

@garybuhrmaster boy.. SAG rules are a picky! You would think if the guest is really a "star" they would want to always highlight it.

jpoet commented 3 years ago

@rmeden MythTV is coded such that either method will work and not cause older versions of MythTV any grief.

Personally, I would probably lean towards adding guest as an attribute of actor. For one thing, that alleviates the need to choose between Guest Actor and Guest Star :-)

honir commented 3 years ago

The change (I am proposing) for the dtd would be something like [...]

Use cases:

9 to 5 <actor role="Doralee Rhodes">Dolly Parton</actor>

Hannah Montana <actor role="Aunt Dolly" guest="yes">Dolly Parton</actor>

The Simpsons <actor role="self" guest="yes">Dolly Parton</actor>

Saturday Night Live <guest>Dolly Parton</guest>

Looks good to me :-)

. (Aside: I think tv_imdb separates out talk-show hosts as 'presenter' and narrators as 'commentator', rather than 'actor' )

garybuhrmaster commented 3 years ago

To keep things moving, I have created a pull request doing what (I think) appears to be the consensus.

rmeden commented 3 years ago

On 4/3/2021 12:23 PM, Gary Buhrmaster wrote:

To keep things moving, I have created a pull request doing what (I think) appears to be the consensus.

yea, the consensus is attribute. xmltv.pm will also need to be updated.

I'm fighting a stomach bug right now, finally got out of bed! (7pm)

garybuhrmaster commented 3 years ago

On 4/3/2021 12:23 PM, Gary Buhrmaster wrote: To keep things moving, I have created a pull request doing what (I think) appears to be the consensus. yea, the consensus is attribute. xmltv.pm will also need to be updated. I'm fighting a stomach bug right now, finally got out of bed! (7pm)

Hope (by now, months later) you are well.

Any update on moving forward here?

honir commented 2 years ago

Are we going ahead with this?

garybuhrmaster commented 2 years ago

Are we going ahead with this?

I believe there was agreement from all to do so, and updating the DTD (could be done via the pull request) was the first step. Furthermore Robert wanted to add support in xmltv.pm for improved support elsewhere in the ecosystem to take advantage of the new attribute, although I do not believe those changes are required before updating the DTD. I believe we should just merge the pull request, and close this issue, and open another for the xmltv.pm improvements.

honir commented 2 years ago

xmltv.pm updated to handle new 'guest' attribute on 'actor'