Roku Developer Program

[Oak-Beard]

I've got a project where I have to deal with metadata files describing all sorts of things (i.e, rating, running time, cast, etc). Currently the files are in XML using a schema I can not change. Multiple namespaces are used. As an example, here is a small subset from a file that uses ~ 450 lines of XML to describe 1 single movie:

<manifest:Inventory>
   <manifest:Video VideoTrackID="md:vidtrackid:eidr-s:10.5240/82DD-86B7-876E-14A1-734F-M">
        <md:Picture/>
               <manifest:ContainerReference>
                        <manifest:ContainerLocation>http://ia700508.us.archive.org/20/items/Sita_Sings_the_Blues/Sita_Sings_the_Blues_720p.mp4</manifest:ContainerLocation>
               </manifest:ContainerReference>
    </manifest:Video>

While I can not change the XML, I do have the option of converting it to JSON. To-date I have not used the XML capabilities in either Brightscript or the roXMLElement. To be honest, the available documentation looks virtually non-existent and I didn't see much on the forum beyond the basics. I would need to deal with xPath queries against multiple namespaces. Then there is the question of relative performance The question in my mind, therefore, is what would more experienced members of the community suggest: go with JSON or XML?

Inquiring minds want to know :?

[EnTerr]

Convert server-side to JSON, if not too inconvenient for you. On client side, you'll get JSON parsed to nested [lists] and {hashes} - that good with you? Bases on your description, sending compact JSON instead will massively decrease network traffic - but more importantly you'll be able to use multiple tools and technologies on the server side if needed - and you can upgrade/update that without having to re-publish the Roku app. Provided you have application server, by all means do as much as possible on its side.

[TheEndless]

There's also no support for XPath queries or namespaces in Roku's XML implementation, so you wouldn't be able to use any of the XML shortcuts available to you (i.e., dot and @ notation), which would make parsing that XML a real pain. I agree with EnTerr, JSON is definitely the way to go.

[belltown]

I definitely would not recommend serving your existing XML to the Roku, given the size and complexity of the data. So it would seem that transforming it to another form on the server-side would be the way to go.

Since the data is already in XML format, if you're comfortable with handling XML, and your server has good XML and XPath support, one option would be to use XPath queries, etc. to transform the existing XML format into smaller and simpler XML at the server. You could include only the data you'll really need on the Roku, get rid of the namespace prefixes, shorten the element names to save bandwidth, etc. Once you get the data in this form over to the Roku, there is very good support for handling XML data, both in the BrightScript language (dot operator and @ operator), and via BrightScript components (roXMLElement and roXMLList).

Of course, transforming your XML into Json within your server is also an option. You may find Json easier to handle on the Roku side, but it might take a little more work at the server end to change the XML into Json. If it was up to me, I'd use XML. However, if you find yourself struggling to learn Roku/BrightScript development, but don't think you'll have any trouble transforming your XML to Json on your server then that may be a better option for you. Either way, it will pay to simplify the data you send to the Roku to keep the bandwidth usage down. Parsing performance should not be an issue; both Json and XML are parsed fairly quickly on the Roku.

[Oak-Beard]

Thanks for all the responses. These pretty much confirm my initial impression that JSON was the better choice but I was afraid I was overlooking something that would tilt the scale back in favor of XML. A server-side conversion to JSON is no problem (I already have code that does that). Regarding belltown's alternative idea of passing to the Roku only XML that had been pre-processed and simplified on the server (e.g., small chunks and without namespaces), I agree its feasible but I think it would have 2 disadvantages: (a) much harder to write, debug, and maintain the server-side code and (b) a much heavier traffic load on the server due to the increased frequency of requests. It also runs a risk of introducing response delays that are visible to the user.

I'm going to go with the "convert to JSON" approach.

Thanks again to EnTerr, TheEndless, and belltown for the feedback.