RadioEPG Specification Ratification

[Ben Poor]

Dear All,

Just to update you on upcoming plans for the RadioEPG specification, especially resulting from last months RadioDNS GA in Geneva.

I'm going to be guiding the specification through to a (hopeful) final ratification next month at the next RadioDNS GA, giving us a few weeks to tidy up the remaining questions. From my survey of topics there appear to be no significant stumbling blocks or points of objects, although there are some clarifications and possible alterations of the document formats.

I'd like to cover these off in as quick a process as possible - they have now been in circulation for a long enough time period that enough feedback should have been collated. What I will do is summarise these issues, any remaining options, or the path that has already been nominated as most appropriate.

If you do have any issues that you would like discussed then please do raise them as quickly as possible. It is important that we move with a reasonable pace on this, especially given the amount of interest being shown in the project from people across the globe.

Ben

[Evain, Jean-Pierre]

Hi Ben,

 

I know I haven’t been ultra speedy in following up but could you post me the latest version just to make sure I am in sync.

 

Thanks in advance and best regards,

 

Jean-Pierre

---

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

[Ben Poor]

Dear all,

In anticipation of my compiling a list of outstanding issues, I attach the latest draft as I have of the RadioEPG specification.

One thing I have done from the last draft that did the rounds, is do some styling of the document to fit in with how I have been working the RadioVIS specification. Nothing too dramatic but hopefully we can work towards a single format.

This has also given me the opportunity to check through the document and sanity check the phrasings, which have now been tweaked. Again, this does not change anything functionally from the last draft, except clarifying some points and providing the right emphasis.

Please do also take this opportunity to check through the document and see if it makes sense for your own purposes. I'm constantly mindful of how important getting this right for the 1.0.0 release is, and I can only do that with all your help.

For those who have not seen this document before - the straightforward part of the specification is the discovery aspects and explanations of extensions to the core DAB EPG XML format. The interesting bits are the discussion on behaviours surrounding Service Following.

As promised, I'll follow this up with questions still outstanding, but please do let me know if you have anything to say in the meantime.

Kind regards,

Ben

[Evain, Jean-Pierre]

Dear Ben,

 

I am looking at the document right now.

 

A first comment: you have a misplaced closing </sequence> tag in the groupType definition. It should be moved before the ID attribute. The xsd may be correct but I don’t have and worked from what I could extract from the PDF.

 

Now I’ll look at the real meat.

 

Best regards,

 

Jean-Pierre

[Evain, Jean-Pierre]

Hello Ben,

 

It is probably too late for that sort of comments but and you probably had good reasons to do otherwise but maybe more compatibility might have preserved with DAB:

 

-          Why didn’t you keep the “ensemble/services/service” (and add ensemble/groups/group) hierarchy (I agree that optional ‘services’ in plural with ‘service’ one to many is not the lightest way of expressing this in comparison to service 0 to many but…)

-          Ensemble only with the service and group children

-          Doing this, all you needed was to add the group element (or groups/group), see above

-          And trim the elements under service and group -> mostly adding / extending with a couple of elements

o   Under service, you may wonder if it was really necessary to remove ‘simulcast’ and ‘epgLanguage’, or even ‘CA’ and not use these in RadioEpg, which would have maintained an even higher degree of compliance with DAB?

o   Then you add memberOf and radioDns

 

What do you think?

 

Best regards,

 

Jean-Pierre

 

From: radioepg-...@googlegroups.com [mailto:radioepg-...@googlegroups.com] On Behalf Of Ben Poor
Sent: dimanche, 18. mars 2012 20:41
To: radioepg-...@googlegroups.com
Subject: Re: RadioEPG Specification Ratification

 

Dear all,

[Ben Poor]

Hi Jean-Pierre,

Never too late for comments - I know we've had discussions on some of
these topics on the list over the time of development, but I'll try to
summarise some of the conclusions we came to:

> -          Why didn’t you keep the “ensemble/services/service”

We cannot use <ensemble> as this is a DAB-specific feature and we're
creating a format that allows both DAB and non-DAB bearers. I expect
the majority of services expressed in the XSI format to be on non-DAB
bearers, and have no equivalent DAB bearer.

> Under service, you may wonder if it was really necessary to remove
> ‘simulcast’ and ‘epgLanguage’, or even ‘CA’ and not use these in RadioEpg,
> which would have maintained an even higher degree of compliance with DAB?

The simulcast element was removed as it was deemed to be obsolete in
the context of what the XSI is trying to achieve. Again, the XSI is
bearer neutral and so all bearers the service is on are listed under
its entry. The simulcast element in DAB EPG XML appears as this
specification is focused on DAB.

The epgLanguage element was removed as it was deemed no useful enough
for inclusion, as was CA. Those two could probably trigger off a
separate conversation between ourselves as to their exact purpose
within DAB EPG XML but that might be better done more informally.
Certainly re-reading their definitions I feel they add nothing to
RadioEPG.

I think at an early stage we realised that we had to break off the
RadioEPG service document into a separate format - the XSI. This was
mostly due to the DAB-specific nature of the DAB EPG XML SI file
format.

There is still an amount of commonality between the two documents,
such that they can be created from the same source, but the
differences in their purposes makes keeping them as separate,
practical.

Hope that explains some of the thinking a bit better.

Ben

[Evain, Jean-Pierre]

Ok then, fine. :--)

Regards, Jean-Pierre

Hi Jean-Pierre,

Ben

------------------------------------------------------------------------------

[Evain, Jean-Pierre]

Oups, juts one last point. If only removing ensemble makes it non-DAB compliant, then so be it but you could actually have made ensemble both DAB and non-DAB compliant.

Just for fun :--)

Ok then, fine (again)

[Ben Poor]

Yes we did consider that, but then you end up with an amount of 'dummy' data (e.g. the Ensemble ID) or elements that are not used for the majority of service providers (ensemble frequency).

We also needed to break compatibility at other points - e.g. by redefining the ServiceID element to hold non-DAB bearers, etc. 

We have tested out elsewhere the suggestions you make and it worked out to be a bit of a disappointing experience. But we are big fans of the core elements, so we used those instead!

Ben

[Nick Piggott (RadioDNS)]

Well handled, btw.

J-P was on the original IMDA meetings, and was initially keen to use the DAB EPG XML. Then when we proposed discarding the <ensemble> element as the root element, he got quite upset. It may be that since then (2 years ago?) the reality has become a bit more pragmatic,

Nick

--
Nick Piggott
Chairperson
RadioDNS Project

http://radiodns.org // @RadioDNS

[Evain, Jean-Pierre]

Nick,

Interesting. I don't think that this last email of yours was necessary.

Let's make things clearer.

I had a look because I was asked by colleagues and Ben to do so but really I haven't had any interest for this for years (and still don't have actually).

I still believe that the <ensemble> could have been kept if you have read the thread. I am therefore entirely consistent and haven't changed my mind. I still believe that higher compatibility with DAB's EPg could have been maintained. Thank-you for pointing out that same review after 2 years led to the same conclusion. That's quite an achievement :--)

I am pragmatic in letting it go without any further discussion because I just don't want to waste of time, which is a precious resource.

Jean-Pierre

________________________________________
From: radioepg-...@googlegroups.com [radioepg-...@googlegroups.com] On Behalf Of Nick Piggott (RadioDNS) [nick.p...@radiodns.org]
Sent: 25 March 2012 11:11

Well handled, btw.

Nick

Ben

Just for fun :--)

Ok then, fine (again)

Jean-Pierre

Ok then, fine. :--)

Regards, Jean-Pierre

Hi Jean-Pierre,

Ben

http://radiodns.org // @RadioDNS

[Nick Piggott (RadioDNS)]

Hello

My last email was inappropriate and I have apologised to Jean-Pierre directly. It was written in a hurry and only intended for Ben to quickly provide some context to previous discussions. I should have more carefully said that J-P was concerned about amending the <ensemble> element. The discussion that prompted is similar to the one here.

I've reassured J-P that his input, as with everyone who takes the time to contribute, is valued and considered.

Nick