Net-top-box, InfoGlue and MIME/media types…
(2 votes, average: 4 out of 5)
Loading ...We run a “digital signage” screen in our foyer - in other words it’s a large plasma screen displaying some static content (and also ‘live’ content such as TV) that is simply served from a box. The box (aka “net-top-box”) is a certain ‘NTB115′ from a company named OneLan; it runs Mandrake and has been described elsewhere as a “Mini-ITX board in a nice case with a video output card”. It has a reasonable web interface for customisation of the content layout but you can also configure it via local xml files directly.
Whilst it is reasonably flexible in displaying TV or static web content, some of it’s features are not so design friendly, such as RSS feed inclusion. With these feeds, you’re only able to style the font of the heading and subsequent description - not the width of the RSS area on the screen, nor the length of the content itself (first 200 characters only? Sorry.). Consequently if you run out of space the RSS feed simply truncates, and so you’re limited to displaying an RSS area as one long line (no line breaks) in order for it to be readable, as you can’t wrap it.
As I wanted to pull and also display (via the net-top-box) our own RSS content from our CMS (we use InfoGlue), I thought that it would be easier to ‘pull’ the content into a CMS resident HTML ‘page’, style it there and then (whilst still within the CMS), and *then* call that resulting page into the net-top-box layout as an ‘HTML content area’ (you only get two choices here - RSS their way or an HTML link). Since our RSS content is already XML, the best way to generate a styled HTML page from it is obviously to transform it via XSLT. We don’t really create a page as create a static url to a xml file which in turn references an xslt file - so the transformation (and resulting HTML) is done on the net-top-box and not within InfoGlue. There’s nothing in the manual to say you can’t do this, but also nothing to say you can, either.
Simple in theory - but it turned into a bit of a pain. It’s difficult to know (unless you’re a linux expert - I’m not, I’m a web designer) exactly how the innards of the net-top-box work as regards reading HTML straight off the bat or having to render it from a transformed XML file, but I do know it transforms it’s own XML files, so there’s a XSLT processor in there somewhere. When it came to test the files from the CMS on the box, the result on the display screen was simply a blank area, which usually denotes whitespace issues, character-encoding issues or simpy badly formed XML, but having eliminated any of these causes I was left with a CMS vs. net-top-box puzzle - eg. something in the way the files are generated and then called didn’t match.
It turned out to be the media types (after much testing) - no errors as such, but just a rather odd way they are treated within InfoGlue or within the net-top-box (exactly which system, I’m still unsure of). For an xml or xsl file to exist within InfoGlue it has to have (in our CMS structure anyway) a content-type defined - additionally a media or output method can be explicitly defined in the file itself. The RSS xml file contains a reference to <?xml-stylesheet type="text/xml" href="xslstylesheetname"?> - at this point, I expected the content-type contained within the xml file to be referencing the stylesheet as type=”text/xsl” - not type=”text/xml” - but it needs to be “text/xml” if it’s to work. The CMS at this point has this same xml file itself as being of content-type “text/xml” (which is also correct, as it’s not an XHTML file).
The xsl file has its output-method as <xsl:output method="html"/>, again as expected as the first child of the root node is going to be <html>, but the InfoGlue content-type for this file, for some reason, *has* to be “application/xml” - or it simply won’t marry the two files up. Again, at this point, I would have expected the content-type to be type=”text/xsl” (even though “text/xsl” it is not considered to be the appropriate MIME type for XSLT files, it has to be for Internet Explorer to render it, and IE is the engine in the net-top-box for displaying content…).
So my conclusion is that it’s a MIME type issue - whether it’s the net-top-box not having the MIME types needed configured, or whether it’s an IE issue, or both, I’m not sure. Buy hey, it works, at last. ;-)