From: Ed A. <ed...@me...> - 2003-05-04 18:52:28
|
On Sun, 4 May 2003, Ben Bucksch wrote: >TV Movie data is often several paragraphs, yes. Hmm maybe I will add <p> then. (But probably XHTML style with <p>...</p>, and then only for <desc> and other things which are intended to be long text.) >However, when I added the detailed rating to the description, I >wished I had HTML available, to make it an itemized list. But of course in this case, it was information that should be stored more directly in the XMLTV format. As I see it, any information which is structured enough for a computer program to generate HTML lists, tables or paragraphs is structured enough to be represented directly in the XMLTV format. It's only in the case that the upstream listings feed itself has text markup that we should consider adding it (as with paragraphs in the description). >(In fact, MythTV already understands HTML in the description, it >seems - it correctly deals with "<br>" in there.) I'm sure that is not correct, it is a heinous bug. The software is failing to HTML-quote text correctly. Suppose the description contained the string 'x < y', would this then start some bogus <y> element continuing until the end of the description? But anyway, MythTV's peculiarities are not my concern - and who knows, perhaps it is the correct behaviour after all for some reason I haven't grasped. >I just think that any text longer than a paragraph should be >structured. If it is structured in the upstream feed, we can preserve that structure or at least some of it. What I could do is define a <p> element and then the content of <desc> will be one one or more <p>s. But <title> and other things will be just #PCDATA as before. This makes it clearer that some elements have 'paragraph content' while others are meant to be short text. A peculiarity of the old XMLTV format was the rule that newlines were not allowed in element content unless the element explicitly said so. I might keep this restriction, but express it a bit more in the DTD and a bit less with comments, by allowing newlines within <p> and not in any other #PCDATA content. >Surround is different from stereo and uses 4+ speakers. In that case 'quadrophonic' or 'quad' might be the best term to use? >Dolby Surround is a certain (patented even, IIRC) and extremely >widespread, analog way to encode surround using only 2 analog audio >channels, and it's backwards-compatible to stereo, so you can use >traditional stereo media to transport it. They do some audio tricks >with inversion and whatnot to encode one additional rear channel in >the 2 stereo channels. It's not audible on stereo systems, but dolby >surround decoders can filter it out and get a range-limited, mono >rear channel out of it. Ah, I see that it is really three channels. But 'triphonic' would be an obscure word nobody would understand. >Dolby Digital (formerly AC3) is a digital encoding for surround, >kind of an MP3 for 6 speakers (front left/right, rear left/right, >center and subwoofer), and thus not backwards-compatible to stereo. But I suppose if you have a digital receiver, you can still listen to the programme on your two speakers or even on a single speaker. Or do there exist digital receivers that can't understand Dolby Digital, and so it is necessary for the broadcaster to send a plain old stereo track as well? >There is also DTS and a Sony system, both digital, but I think only >used on DVDs, not TV. Anyways, "surround" is thus ambiguous. I'm just not that keen on adding trademarks or names of proprietary systems to the DTD, although they can appear in the file format. Maybe the answer is to have a 'system' attribute, for example <mono> <stereo system="nicam"> <surround system="ac3"> Those 'system' strings would be application-defined. But we probably only need the three choices for element name. Would this suffice? -- Ed Avis <ed...@me...> |