RFC: XML / XSLT spec for Hijack playlists

Hi all. So, I've done some work on this to update the XML / XSLT to how it looks in v199 (just for a baseline). Thing is, the Hijack playlists are more complicated now (which is good), so this requires the use of math and string functions in the XSLT.

Problem: Anyone using a browser that can only use the working draft spec of XSLT (e.g. IE 5 & 5.5) can't use these functions, as they weren't defined in the working draft spec.

Solution 1: Have Hijack put enough information in the XML so that we don't have to do any math or string functions. This would be things like making length for playlists divide by four, and making length (actually duration) for tunes do the math necessary to convert to minutes and seconds. Also, we'd need to pass the tag file fid, and the music file fid (both of them are used in the links). Yes, this seems totally lame, but I at least, can't think of a way around it with the working draft spec.

Note that right now, this math is being done in Hijack, because it gets sent down in the HTML the "right" way. So, this might not be that big a deal. I was just going on the actual data in the tag files as a baseline, so that there would be no conversions necessary in Hijack, we could do it on the client.

Solution 2: Have anyone that a) wants to use the XML / XSLT and b) wants to keep using IE 5/5.5 (and not upgrade to 6.0), at least upgrade their XML parser to MSXML 3.0. I can provide details on how to do this.

Note that this shouldn't affect Mozilla, as it only provides support for the 1.0 spec of XSLT.

I post this at the risk of "told you so's" from those that didn't think we could support it across platforms. I still believe we can (actually, I know we can), the question I put to you (including Mark), is how should we do it? Force all downlevel IE browsers to upgrade either to IE 6, or at a minimum MSXML 3.0 (keeping IE5.x), or provide the extra data in the xml, so that the math and string functions aren't necessary.

Personally, I prefer the second solution, as I think people should attempt to stay current with technology, and the first solution is a bit of a hack. But either is fine with me, I'd like to hear Mark's comments if any.

Comments appreciated. When this gets somewhat resolved, I'll post what I have for format suggestions and working XSLT.

Chris

Hey thats good news crocklobster.

My input to all this is that you should output as much info as you can to allow both versions in the same XML file. You may care to structure the XML file so that level 1 consumers can easily locate the stuff they need while level 2 consumers can get at the raw data easily as well, rather than mixing it all up it might be easier to have 2 sub-nodes in the XML tree for each song - 1 with all the level 1 stuff in it, the other with the level 2 (i.e. raw) data.

The level 1 consumers (those browsers not capable of doing their own math) should have the same (or more) XML fields available to them for their playlists than they get now in raw html.

Level 2 consumers (those that can do their own math) can manufacture what they need from the base data, and can then crib whatever data is also available in the file for the level 1 consumers - (this should include the fids for song and tag files as well as whatever information we have available from the database file).

The reason for including the fids/drive # of fids etc is that with this sort of information we can construct a full path to the tag or song itself and if needed actually open and extract additional (non-XML) data at the client-side if needed to provide additional enhanced playlist functionality.

I am not sure how much work is required of Hijack to implement the first solution [to support downlevel browsers]. But once its done it would be useful to still output the info for more advanced consumers.

In general I would expect any XML file to output as much information as it has available (and can make available fairly easily) from day 1 - the resultant XML file will not be large enough that including everything will slow things down and it will ensure that the potential users of this file are larger than if we do a cut down version and then extend it.

Thats my input.

Okay, here is a proposed format of the playlist xml. Mostly what I did was look at the tags, what they might include and put them in a structure that made at least some sense to me.

I ended up taking out the math and string functions and putting the necessary information in the xml. Note that if you wanted the actual data, and you're using the XSLT 1.0 spec, you can do the math yourself to get back to the actual data.

For those other xml afficianados out there, feel free to provide constructive criticisms. Thing is, it really doesn't much matter which of several formats we use. I mean, the data has to be grouped by item (whether that is a playlist or a tune). Other than that it's flexible and hard to say which is better or worse than any other. I could have just made each entry in the playlist its own element with a bunch of attributes, or made more nesting than I did. This is what I picked, it works, and I think it will suit our needs. Let me know if you think I'm crazy. What I really want if for Mark to look at this as a guideline and make whatever is easiest in the fewest lines of code. Whatever the format ends up being, we can write the stylesheets around it.

Someone earlier had suggested the format of the XML export function of emplode. I looked at that, and it's not appropriate in this case. That format is more for exporting an entire database, not for describing individual playlists.

In this zip file, I have included two stylesheets. They are differentiated by which version of the XSLT spec they use.

currentList - WD.xsl uses the working draft spec of XSLT, and should be used with IE 5 / 5.5 if you don't have the MSXML 3.0 parser installed.
currentList - 1.0.xsl uses the 1.0 spec of XSLT and should be used by IE6 and Mozilla.

You'll have to rename either one of these to just currentList.xsl

The other file is the sample xml file that shows both playlists and tunes in one list (just for the example). If you double click on the xml file, it will open in your browser and the stylesheet will be applied to it. You'll notice that right now, it looks strickingly similar to the current playlists in v200 of Hijack.

As far as the "protocol" for getting xml from Hijack, here's what I propose:

A config.ini setting for a default stylesheet to apply, this is applied in the xml-stylesheet processing instruction. In this sample case, the entry in the config.ini would be currentList.xsl

A format for requesting the xml of a playlist like this:
http://my.empeg/drive0/fids/101?.xml&xslt=mystylesheet.xsl
Where:
the &xslt is optional and if provided, will override the entry in config.ini
the value for &xslt is a relative or absolute path of the stylesheet to use (remember the browser is what makes this request, so it just has to be in the format that the browser can understand)

Mark would need to provide for the downloading of the stylesheet, as a file, even if khttpd_files was equal to 0 (in my opinion, as it would be vital even for browsing, and you'll be able to enforce security through the xslt by how many links you put on).
He would also need to select a directory that makes sense to him for putting the stylesheets that one asks for with a relative path (or no path). (Maybe that's the fids directory, I don't know)

I hope all this makes sense. I'd love to answer any questions, but I'm going skiing for four days. I hope to get back to this on Monday. Who knows, by then it might be implemented and we have 15 stylesheets to play with. Oh, except Mark said he was retiring for a week too. Well, maybe that's good.

Chris

In reply to:

---

Someone earlier had suggested the format of the XML export function of emplode. I looked at that, and it's not appropriate in this case. That format is more for exporting an entire database, not for describing individual playlists.

---

That was me . I hadn't actually looked in any depth at the format of the XML spewed out by Emplode at the time (well I still haven't). If you say it's not suitable then that's ok, just thought I'd remind ppl that a format did exist already.

Your format looks nice & straightforward and should do quite nicely AFAICS. I've just one question: Do we need the following in the playlist definition?

<bitrate></bitrate>
<samplerate></samplerate>
<codec></codec>
<offset></offset>

Maybe I'm missing something?

Hey crocklobster, just looked into your XML format.

Great job, its got everything I think we need in there.

beaker:
re inclusion of:

<bitrate></bitrate>
<samplerate></samplerate>
<codec></codec>
<offset></offset>

in the XML, well we want to allow all the fields available to be published in the XML (even if its not there most of the time) as this means that anyone who does want to use it can, and it can also be used for searching and sorting.

Also, while the format of
<bitrate></bitrate>
in the XML file seems to use a lot of 'bytes' for no good reason, this can be shortened to
<bitrate/> which is the same thing in a (officially supported) shorter way.
Having 'wasted' 10 bytes in a entry to show no bitrate, but also reserving room for it to appear if present is in my book sound.
Look at the size of the XML file output - its only a few kb.

All in all I think Crocklobster has done a brilliant first cut and its got my vote for asking Mark Lord to implement it when he gets time.

crocklobster: have you a schema for the XML file? If so, care to publish it also?
If not, any plans to make one?

Correct me if I'm wrong but won't the fields I listed always be empty for playlists? I'm not talking of tracks, just playlists.

wow, looks great...
can't wait to see it with my songs on it

Yeah I guess you're right.
In which case they probably should be left out for playlists as they will never be used (not in V1 of the XML format anyway), unless it complicates things in the kernel routines outputting the XML.

Yeah beaker, you're right. I should have eliminated bitrate, codec, and samplerate from the playlists. You'll notice I did leave them off of the list of <currentList> attributes.

As far as a schema, I could make one (quite easily with XMLSpy), I'm just not sure how useful it would be. Is anyone going to be validating that the xml that comes from the player is valid according to the schema? To me, the schema is whatever Mark says it is. I just provided something that should give him an idea of what we're thinking. I leave it to him to put it together the way that makes the most sense programatically.

Okay, so now that we seem to like this format...want to make an enhancement or two to the xslt? That will really show the usefulness of this and maybe inspire Mark to add this to the hotlist of features. What were some of the requests? Alternate coloring of the rows. Oh, and icons for playing vs. streaming. I'll see what I can bust out today.

Chris

Well, here's a quick alternate colour jobbie. The playlist rows are coloured in alternate shades of Blue and Tunes in alternate Yellow & "BlanchedAlmond". I'm no expert at XML or XSLT so there may be a more economical way to do the alternate colour thing but it's a start.

I was excited to see this, but do you think you could do it with the WD version for IE55? I don't really want to upgrade this machine.

Here's a slightly improved version. Just unzip it into somewhere safe and view the XML file in a browser. Hopefully it should call the XSL file and format it correctly.

Forgive me if I'm being a bit dim but what do you mean by 'WD version'?

Working Draft
in the initial zip of xsl's two were there -
currentList - WD.xsl
currentList - 1.0.xsl
1.0 uses strings and math that the WD can't handle

OK I'll take a look at that. It's not going to happen until tomorrow now though. I'm off to bed. Nighty night .

well, I just looked at your code...
I don't know if postion is available in the WD

I've definitely had position() working in versions of IE prior to v6. I did need to upgrade to MSXML 3.0 though I think. Maybe some others may have worked on some alternatives by the time I come back tomorrow.

I really am going to bed now. zzzzzzzzzzzz

Tomorrow I will post links and instructions for updating IE browsers to MSXML 3.0. 4.0 is out now, so you might even consider going to it. It's supposed to be much faster as far as XSLT transformations go. I have not tried it yet though, so I can't vouch for it.

Tonight, here is a slightly altered version of beaker's last post. Someone else had mentioned putting buttons (icons) on the playlists for streaming and playing. Here they are, I took a couple right off of that thread. Not sure it looks all that great, but you get the idea of how this could work.

MSXML4 won't help in this case (for having XML files with XSL processing instructions embedded). This is because MSXML4 does not replace the older MSXML versions, but installs side-by-side with them.

If you want XML files with XSL processing instructions you will need to install MSXML3 (service pack 2 is the latest) and then switch it from "side-by-side" mode to "replace" mode.

Beware, installing MSXML3 in replace mode can, sometimes, break apps (including web/intranet ones) that are using the earlier versions of MSXML. It's all a bit of a mess, which is why MSXML4 only has a side-by-side mode.

MSXML3SP2:
http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/772/msdncompositedoc.xml

MSXML4:
http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/766/msdncompositedoc.xml

Tool for switching from "side-by-side" to "replace":
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/469/msdncompositedoc.xml

P.S. I have just discovered that if you install MSXML3SP2 is installs in replace mode anyway, meaning you don't need to switch from side-by-side mode
P.P.S. With the MSXML "service packs" they are in fact not patches as such, you don't need to install MSXML3 and then apply the service pack, you just need to install the service pack.

Good catch on the MSXML 4.0.

With those links people should be able to upgrade to MSXML 3.0. I'd recommend that for anyone with a 5.x browser.

Now if we can get Mark to take a look at this and see what he can do.

Let's see, where' his paypal account? ;-)

Chris

Okay, just email me with explicit instructions on what you want the kernel to output, and under what conditions it should do so, etc..

I'm playing dumb on this one.

Thanks