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.
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.
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).
"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.
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.
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.
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.
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.
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.
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.
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 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.
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:
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.
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.
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
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.
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.
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.
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
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:
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?
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?
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).
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
}
}
73 comments
[ 0.23 ms ] story [ 155 ms ] threadIs there a reason (legal or otherwise) that they can't just use HTML?
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.
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/
You know, without namespaces, you take out the eXtensibility-bit.
SGML, actually. "Just markup" can entail other things, like TeX, for example.
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.
https://news.ycombinator.com/item?id=10194839
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).
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?
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.
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.
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.
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.
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.
Not television the broadcast medium, but television the giant Samsung device in your living room.
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.
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
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.
I really would have liked that XHTML had won.
https://developer.apple.com/library/prerelease/tvos/document...
The (arbitrary) template page linked to has visualizations and code samples. Much better.
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).
https://github.com/iBaa/PlexConnect
If you need to add namespaces, then you have already failed.
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
Then in version 2 you support multiple screens, so now you want Example #2 should be an error in schema v1, and example #1 should be an error in schema v2Part of that problem is solved with schema versioning and part of it is solved with namespaces.
Doing more isn't a good thing.
EDIT: I think someone is probably down-voting me for a technical reason. Would you please explain it?
Apple is really good about giving developers a heads up before deprecating anything.
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
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.
<p>Hello, <strong>dave</strong></p>
Conversely, this is pretty painful to describe in XML:
<pair> <key>name</key> <value type="string">dave</value> </pair>
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_...
I am working on a new language concept (still at early thinking) but the alert template document would be defined as: