Re: XMLTV 1.3.0 released!

On Fri, 28 Jun 2024 02:52:31 +0000, Gary Buhrmaster wrote:

> On Thu, Jun 27, 2024 at 10:02?PM Robert Eden <[email protected]> wrote:
> 
> > Gary makes an excellent point...  when you run a parser in default mode,
> > a node with multiple items becomes an array.  So changing from audio? to
> > audio* may break some apps.
> >
> > Is there anything in the DTD that reports multiple audio streams?  I
> > don't see it.  If so, maybe adding a  subchannel* element under audio
> > isn't a bad idea.   (with descriptive attributes of course)
> 
> SAP support is clearly a shortcoming, but things do
> get interesting, as the SAP streams can offer
> multiple languages so you need to handle that in
> any proposed changes, and some SAP streams
> might be in various formats (DD5.1 in Spanish, but
> only stereo in English?), and as not all "visual-described"
> programs are actually alternative SAP streams (in
> some cases you can set your TV to "merge" your
> primary audio stream an some "visual-described"
> stream, and (I suppose) those can even be in different
> languages, and specify alternative volume levels), not
> that that does not mean that the DTD can represent
> that as a SAP audio stream.
> 
> I'll point out that the proposed trival addition to add
> a "visual-described" subtitle type *can* already be
> offered in multiple languages, so:
>   <subtitle lang="English" type="visual-described">
>   <subtitle type="closed-caption">
>   <subtitle lang="Spanish", type=visual-described">
> could all exist, although that can not represent
> the full details that a more complete SAP
> specification might be able to do.


Perhaps we need a new <programme> element for "broadcast features" (better word required..."services"? "resources"?).

I don't think we need to rigidly follow the transport stream setup - since that too has been cobbled by changing services over last 20 years, and has its own anachronisms. So just because something is in the audio stream I don't think we need to put it in an <audio> style element.

We could abstract these 'modern' features into a new element, which cuts across (i.e. is not restricted by) source stream.

So we could have a new <programme> element, say:
 <accessibility type="audio-described" lang="English">
 <accessibility type="audio-described" lang="Spanish">
 <accessibility type="deaf-signed" lang="BSL">

We could deprecate "deaf-signed" from the <subtitles> element and move it here also. (With a language option for British Sign Language, etc)

Sorry Robert but we are stuck with "AD" (Audio Described) in the UK :-(  The BBC's reasoning being it is a description *using* audio rather than *of* the audio. But we should also allow "visual-described" and others according to the grabber's region.

This might (or not) offer some level of future-proofing for future additions to digital technology?...maybe.

Geoff