Apple TV Markup Language | Hacker News Reader

Apple TV Markup Language

developer.apple.com

108 pointshharnisch68 comments

If any of the authors are reading, you really ought to consider putting this into an XML namespace. It can just be a mysterious invocation to most users today, but if you need to extend this in the future (inline SVG? inline XHTML?), it'll save your bacon to have done it in the first version.

Why would anyone add complexity to the syntax when you can make it simpler by removing the XML namespace?

If you need to add namespaces, then you have already failed.

If you have XML namespaces, you can embed foreign XML types in your XML (like the grandparent's SVG example) and also keep your schema-validating XML generators/parsers. That's good for the same reason static type checking is good.

It can also simplify the code that parses it. With an SVG XML document embedded right in your TV XML document, you can e.g. use your functions that take an SVG node regardless of whether it was the root node of a document or embedded in another document and render it to the screen.

It can also let you do versioning. For instance, let's give a schema like

    <render>
        <image src="..." />
    </render>

Then in version 2 you support multiple screens, so now you want

    <render>
        <screen number="1">
            <image src="..." />
        </screen>
        <screen number="2">
            <image src="..." />
        </screen>
    </render>

Example #2 should be an error in schema v1, and example #1 should be an error in schema v2

Part of that problem is solved with schema versioning and part of it is solved with namespaces.

You can do all sorts of stuff if you make it more complicated.

Doing more isn't a good thing.

It's if you want to have backwards compatible syntax supported by later devices. This will naturally happen as you add features and modify old ones. It's even more important in hardware devices that might might not be able to be updated later.

EDIT: I think someone is probably down-voting me for a technical reason. Would you please explain it?

If Apple wants to break BC they just do it. They control the entire ecosystem and has been known to break stuff pretty frequently and force everyone to keep up

I imagine they break stuff frequently, but not as frequently as they could if they wanted - though someone from Apple would know better than me of course.

> been known to break stuff pretty frequently

Apple is really good about giving developers a heads up before deprecating anything.

As I understand it, you don't need to worry about backwards compatibility. You submit these pseudo-XML views along with your app when you publish it but what they do from there on out is up to them - they could "recompile" them to newer versions, they could compile them to some binary representation, whatever. But anyway, it's not your problem. Your responsibility is getting the app to the app store, their problem is getting the app from the app store to the devices, in whatever format they see fit. Despite the technological similarities, this isn't publishing to the web where you have to handle everything by yourself.

At this point in development, it would manifest by adding the attribute

    xmlns="http://apple.com/TVML/1.0"

(or similar) to the top-level tag.

And absolutely nothing else has to change.

For that matter, even ignoring the issues of being able to embed foreign content later, just sheer versioning is a good enough reason to add that. And once you agree versioning is a good idea, why not do it via namespace? It's not like

    version="1.0"

is materially different or shorter.

If you're expressing a certain crabbiness about this being in XML in the first place, you'd have to take that up with Apple. But once you're using XML, you ought to take advantage of what comes with it.

No, he just means adding a default namespace, it's a one-liner and shouldn't make anything more complicated

Can't you add support for SVG and XHTML without this? Unless I'm missing something, you just need to put the appropriate `xmlns="..."` attribute on the root element of the SVG/XHTML embed.

I believe this XML+JS thing was the only way to write apps for the old Apple TV. Various postings on the internet seem to suggest this from way back; the old SDK was probably only ever available to a select few handpicked appletv channel partners.

What's new in the new tvOS SDK is that you can also write native apps in Objective-C/Swift, with a main() function that starts up UIKit, and with access to most of the normal iOS APIs (like OpenGL, SceneKit, etc etc).

I was confused at first because TVML seemed more prominent in the marketing/developer materials. But we just saw a game run on Apple TV so yeah, you could write native apps w/o the TVML.

This was confusing for A LOT of people!!

Correct. You could actually modify the HTTP proxy settings and trusted certificates on the device and run your own applications using a man in the middle attack. Plex had a version that supported this:

https://github.com/iBaa/PlexConnect

For anyone wondering about this, I've been using it for a while and it works great - the Trailers app now loads the Plex UI for me. I've barely had to touch it since the initial setup.

I've had worse results -- after a few days, I need to restart the python process as it'll start to block outbound requests.

This should be theoretically compatible with React right? I wonder if Netflix are using this + React for their Apple TV app or if they're doing something entirely different... There is a <divTemplate> option so perhaps its through that?

This is what looks like a css: https://developer.apple.com/library/prerelease/tvos/document...

Oh look, it's XAML for an Apple device.

That's only half-sarcastic; it does seem to be a similar but much-simplified markup language that learned a lot from HTML5. Will be interesting to watch it develop.

As others have commented, though, XML without namespaces is not a fun ride (in my humble experience).

[0] https://en.wikipedia.org/wiki/Extensible_Application_Markup_...

If XHTML had prevailed, we would already had XAML for the web, instead HTML keeps getting hacks.

I'm a little surprised they're jumping into the literal "TV" namespace so wholeheartedly.

Is the future of this ecosystem really exclusively limited to the Television?

Gaming is already an explicit part of this, which undoubtedly will include VR, which is theoretically suited to Television-like content.

If they do this right, the source code running on your VR gogs will mention "TV" everywhere, much like the the current OS running their desktops and mobile devices references a defunct company.

> Is the future of this ecosystem really exclusively limited to the Television?

Not television the broadcast medium, but television the giant Samsung device in your living room.

The iPhone name worked out pretty well, even though the phone functionality is just a small fraction of the iPhone's value proposition.

Apple's phone SDK's are not prefixed "Phone", nor is it called the "Phone OS".

Exactly to my point: It's called iOS because the breadth of it's applicability was recognized from the beginning.

Edit: You're right, and it's different: naming of the mobile OS and namespacing were independent, allowing for a public re-brand without changing any code. Seems the TV is not going that way though.

It was called iPhone OS for a few years.

Splitting hairs here: it was originally iPhone OS in the beginning, but moved to iOS in June 2010

Well, think of the origin of the name, Tele-vision. I'd say that TV is just as appropriate a name for VR as VR is, if not even a little better of a name. We didn't stop calling flying vehicles aircraft when the jetliner was introduced. It's not so bad to call a potential VR platform by the "tv" moniker

"Is the future of this ecosystem really exclusively limited to the Television?

Gaming is already an explicit part of this"

Presumably people won't be writing games with this simple presentation layer optimized for printing lists of multimedia content - for example TV Shows... Games will (mostly) be written in objC/Swift to the Metal APIs, as will many other apps.

This is just a small portion of the app creation ecosystem for the Apple TV, and since it's geared towards things that traditionally are watched on a TV, I think the name is fine.

--edited to clean up the quote

I think TV is an ok reference to "a large screen with a remote control".

The main problem is that we are still using XML to do component definition and composition. We need to better language (no, json and yaml are not the answer).

I am working on a new language concept (still at early thinking) but the alert template document would be defined as:

  alert#update_available [  //Composition is separated from definition
     btn#update,
     btn#cancel
  ]

  alert { //All alert elements are defined as alertTemplate
     type: alertTemplate
  }

  btn { //All btn elements are define as button
     type: button
  }

  alert#update_available { //Define the title and description for the alert with ID update_available
     title: Get the latest tvOS version
     description: Get the latest tvOS version
  }

  btn#update {
     text: Update Now
  }

  btn#cancel {
     text: Cancel
  }

  //We could override the settings like CSS
  (@language = "pt_br") { 
  //If variable language is pt_br override the content with Brazilian Portuguese texts
    btn#update {
       text: Atualize Agora
    }

    btn#cancel {
       text: Cancelar
    }
  }

The link should probably be the main TVML page rather than one of the template reference pages.

https://developer.apple.com/library/prerelease/tvos/document...

The "About TVML" page is far less compelling. Barely better than noise, in the context of a link on the HN front page, without a specific and pre-existing interest in the topic. If OP had linked to that, I personally wouldn't have read any further.

The (arbitrary) template page linked to has visualizations and code samples. Much better.

OP here - You're exactly right, I looked at that front page and almost bailed. I thought this was much more interesting since it shows a simple example with code and matching output screens.

I think it's interesting that Apple is promoting making apps that are web based that you wouldn't have to get approval for to make updates. Maybe because it's limited on you can do with TVML but I think it's interesting.

I don't think that's what's happening here. Each of the TVML documents would be stored locally and called by a locally stored TVJS file, which is invoked by your binary.

In other words, all of the program logic and display elements are on the Apple TV - only the data that's being retrieved and displayed would be stored server-side - which is no different from any iPhone app that displays server based content today.

No the app looks to an outside server for the code. Check out Apple's sample code which makes you run the code on a python server.

So it's just HTML?

Is there a reason (legal or otherwise) that they can't just use HTML?

It's not like HTML except for being XML which looks a lot like SGML.

It's significantly more limited and more specific to the task than HTML. HTML comes with a lot of baggage that makes it unsuitable for a really specific use case.

It's not like HTML except for being XML which looks a lot like SGML.

XML does not only look a lot like SGML, it is a proper subset of SGML:

XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents.

http://www.w3.org/TR/xml11/

Interesting, I didn't realize they claimed XML was an SGML subset. I thought you couldn't express XML empty tags in an SGML DTD.

Unlike HTML, btw, which started out as a loose subset of SGML but has abandoned the goal of SGML compatibility in favour of conceptual simplicity.

No, no, it's not HTML, because everything is inside <alertTemplate>, not <html>.

In no way is this html. its xml. they use xml for the same reason that most do - to define their own elements and behaviors thereof

XML without namespaces, so pretty much just markup.

You know, without namespaces, you take out the eXtensibility-bit.

> pretty much just markup

SGML, actually. "Just markup" can entail other things, like TeX, for example.

Supporting full HTML would much be more processor- and memory-intensive. It also gives developers more freedom, which can negatively impact the user experience.

I don't know if I agree with the tradeoffs they've made here, but those are at least two reasons to create their own custom schema here.

As others have already said, it’s XML. This comment by jonknee back in the other Apple TV thread is a bit more detailed:

https://news.ycombinator.com/item?id=10194839

I'd guess that they don't use full-blown HTML to make sure developers don't go overboard and break the UX.

I have no idea how it's actually implemented, but it's quite likely TVML is powered by HTML (and WebKit).

Rather than expecting developers to use an open-spec-compliant generic toolkit, they've just built modules on top of it to both make development easier and more importantly maintain a consistent UX.

You could just have pre-defined CSS classes and do much of the same thing, but it will not be as elegant nor as controlled. Taking over the HTML and JS interpreters just allows them greater control while respecting the role each component plays (markup, interactivity, styling, etc).

Implementing this with WebKit would be massive overkill; I'd say it's quite unlikely it's implemented with it.

If you implemented a web-like runtime from the ground up, you're saying you would write it from scratch?

The runtime has JavaScript support, it does not have a brand new interpreter.

The runtime has CSS support, it does not have a brand new interpreter.

The runtime has HTML/XML syntax. Why would they write a brand new interpreter?

Because the XML syntax maps directly onto UI components; introducing an HTML canvas is vastly more complicated than that.

Mappping XML to a small subset of UI objects is so simple you don't really need to pull in an entire browser runtime for it.

"So it's just HTML? Is there a reason (legal or otherwise) that they can't just use HTML?"

The BBC have an open source library for building apps for TV based on HTML, CSS and JavaScript called TAL: TV Application Layer. It's designed to be deployed across HTML-based TV devices.

http://fmtvp.github.io/tal/getting-started/introducing-tal.h...

Apple's tvOS is likely to have much richer functionality since it's hosted on Apple's own hardware. However, an open standard for TV apps would be a good thing.

The BBCs TAL was released as open source in March 2013. But I don't know if it's gained wider traction in the industry.

I think the heavy reliance on these templates is a good clue. Apple TV's interaction model is a lot about swiping around from tappable element to tappable element. Arbitrary layouts will make this a miserable experience. Apple probably wants to establish a number of layout patterns that they believe will yield a good experience.

Would you really want full blown hypertext markup styled with css on your apple tv?

Just imagine all of the garish designs that would pop up.

It's better to restrict what is allowed in a custom markup language so that apple has better control over how it is rendered.

Curious on why they chose an XML-like syntax rather than something like JSON

XML is a markup language that can describe formatted document structure well, json is best suited for things like data. For instance, this would be pretty painful to describe in json:

<p>Hello, <strong>dave</strong></p>

Conversely, this is pretty painful to describe in XML:

Good point, forgot about the display portion of this application

So if you're building a simple media app, can you just use the templates and JavaScript without much or any Swift/ObjectiveC? Sort of like Roku and Sonos?

So what's an example of something you could build with this?

Probably something like the MLB app they showed: - Basic streaming - various ajax requests for score listings, etc. - Plus some chrome / UI with app-specific assets

Another mark up language? Why? What was wrong with HTML here?

Much more specific and limited semantics. I would not expect that this is rendered with a web engine.

I'm not sure I'd qualify TVML as another mark up language. It looks like an XML standard that adheres to a particular XML schema. Asking, "Another XML schema?" would sound like a silly question because that's the whole point of XML.

As for why not HTML? I think there's a lot of really good reasons why HTML would be a poor choice. If you want to restrict Apple TV apps and channels to rely on Apple approved idioms, HTML would be a terrible choice. Apple isn't as interested in creating an open TV browser as much as it's interested in creating a unique and positive TV experience. They can shape that with their own standard.

Documents aren't applications.

I really would have liked that XHTML had won.

because a TV screen != Hypertext Document.

Reply on news.ycombinator.com