RFC: Ice XML Guide 2.0

[Russell at IceTV]

Hi guys,

We've been working on some changes for version 2 of the XML guide, and thought we'd run them by you to see if you had any comments or suggestions.  Here are the changes we've made so far:

- All dates and times are now in UTC.

- Removed the "broadcast-type" entity that contained flags such as BW, WS, HD, R, and CC.  Now using fields defined in the original XMLTV spec. for these items (actually the XMLTV spec didn't include a field for HD, so we created a new "quality" entity, but the others were there, just kind of oddly-named):

    <video>
        <colour>yes</colour>
        <aspect>16:9</aspect>
        <quality>HDTV</quality>
    </video>
    <previously-shown/>
    <subtitles type="teletext"/>

- Added a new "ice-xml-version" entity, which shows the version of the XML format we're using.  It's set to 2.0 for this new version of xmlguide.

- Version 2 uses a new DTD, which you can view here:

    http://server.icetv.info/webguide/webguide2.dtd

- Added the current date and time to the "date" element of the "tv" entity at the top, to show when the data was created.  The format is "YYYYMMDDhhmmss" and it's in UTC.  For example:

    <tv date="20050208040012" source-info-url="http://www.zaptv.info" source-info-name="ZapTV" generator-info-name="ZapTV" generator-info-url="http://www.zaptv.info">

- Added the ability to specify a "last modified time" in the URL.  If included, only program records modified after the specified time and date are sent. The usual format is "&mod_time=YYYYMMDDhhmmss", expressed as UTC. This value can be copied from the "date" element of the "tv" entity, which shows the time and date the XML data was created. By sending this value back in a new request as the last modified time, the output can be limited to only those records modified since the last request. This includes any new programs added since the previous request, as well as programs that were sent before, but have since changed.

Comments welcome.

When it's ready for beta testing (soon), we'll post a msg to the Announcements forum.

Thanks,
Russell

[BJReplay]

Hi Russel, that all looks good - especially the move back towards the XMLTV DTD.  That means that I don't need attempt to handle your feed any differently to XMLTV.

It would make my life easier if previously-shown included the date originally show (or the original release date if not known) (e.g. wasn't just an empty element), simply because of the lazy method that I'm using to convert XMLTV to MCE data in QuickGuide.  On the other hand, I can understand if I just have to parse the XML  .

BJ

[Russell at IceTV]

Hi Russel, that all looks good - especially the move back towards the XMLTV DTD.  That means that I don't need attempt to handle your feed any differently to XMLTV.

It would make my life easier if previously-shown included the date originally show (or the original release date if not known) (e.g. wasn't just an empty element), simply because of the lazy method that I'm using to convert XMLTV to MCE data in QuickGuide.  On the other hand, I can understand if I just have to parse the XML  .

BJ

Hmm, well, I don't think we have either of those dates at the moment, so I'm afraid it'll have to stay empty for the time being -- sorry about that.  But that entity is the same as in the XMLTV spec.  Is the problem because there's not an explicit closing tag, or because there's no data between the opening and closing tags?

Russell

[Russell at IceTV]

Just an update...

I said before that all times would now be UTC.  According to the original XMLTV spec, the start and end times can either have an explicit time zone added to them (for example, "20050209130000 +1100") or the time zone can be left off, and UTC is assumed.  It seems that ShowShifter handles this ok, but WebGuide2 seems to have a problem unless there's some sort of time zone included.  But it's ok if I just add "+0000" for the time zone, so we'll go with that unless anyone knows of another problem.

Thanks,
Russell

[BJReplay]

+0000 is fine by me (QuickGuide).

Re the previously-shown element - I'm using a MS .NET DataSet method called LoadXML which loads the xml into several tables according to either a derived or explicit schema. I'm using an explict schema modelled on the XMLTV.DTD, but customised to manage the way the data is loaded into the dataset.

That's pretty neat - my code to load and parse the XML into the data structures I need is literally just:

Code: [Select]

XMLTV.ReadXmlSchema(System.Configuration.ConfigurationSettings.AppSettings["XMLTVSchema"]);
XMLTV.ReadXml(XMLTVFile,XmlReadMode.IgnoreSchema);
Anyway, as a result of the way XML loading works, the end result of an empty element (whether or not it is in the form of <previously-shown></previously-shown> or <previously-shown/> is that the previously-shown column that results is NULL.  However, my problem is that I can't distinguish between a null column where the tag exists, and a null column where the tag does not exist.

Anyway, as I think about it, I can probably change the definition of the previously-shown column to have a non-null default, and then detect explicit nulls (which is how the empty element will be interpreted).  That seems like a workable simple solution.

Cheers

BJ

[BJReplay]

Hmm, well, I don't think we have either of those dates at the moment, so I'm afraid it'll have to stay empty for the time being -- sorry about that.  But that entity is the same as in the XMLTV spec.  Is the problem because there's not an explicit closing tag, or because there's no data between the opening and closing tags?

Russell

Hi Russell, I've confirmed that I can handle the empty element previously-shown for repeats.

ciao

BJ

[Russell at IceTV]

Hi Russell, I've confirmed that I can handle the empty element previously-shown for repeats.

Excellent.  Thanks BJ.

Russell