Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, alex wrote: We have to take into accounts the needs of everyone. This includes large companies. If large companies will only accept codecs that they've already implemented, then that may have to be one of the criteria. This conflicts with: Whatever solution we find will be one that is royalty free and open. That is not in any doubt. You can't have it both ways. We could, if one of the codecs that was implemented by large companies (e.g. H.264 Baseline) was made available royalty-free. It could also be the case that the aforementioned large companies will accept a compromise that doesn't involve a codec they already implement. Currently there is no known solution. That's why we're in this mess. But, as they say, top people are working on this. If the text moves to requiring a non-free codec, then you will have been screwed, and then you should raise almightly hell. However, no such decision has been made (and no such decision will ever be made, at least not while I'm involved). Pfew, can we get a signed copy of that? :P It's already in the spec: # [...] we need a codec that is known to not require per-unit or # per-distributor licensing, that is compatible with the open source # development model [...] The way i see it there are 3 possibilities so far: - use ogg, possible (but negligable) risk of submarine patents This is basically as acceptable to companies like Apple as H.264 is to the free software community. - use extremely old technology Unfortunately this is unlikely to give us the quality we desire, but it is possible that we will have to compromise on this option. - use another free codec which has a 100% guarantee that there are no patentholders lurking this does not exist (afaik) Indeed. At the end of the day, I think little choice remains except ogg. Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text nodes and inter-element whitespace
On Nov 26, 2006 2:38 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: Why isn't the following a conforming block of computer output too: pre !-- XXX ... -- samp12.12.../samp ?test ...? /pre Fixed, along with some examples. -- Ian Hickson
[whatwg] Acronyms (Was: Video proposals)
On Fri, 16 Mar 2007, Robert Brodrecht wrote: Something that is bugging me over on the W3C HTMLWG mailing list is the want to drop acronym in favor of abbr. I'm emotionally attached to acronym. I use it a lot, and really do feel like it is semantically different from abbr. Asbjørn Ulsberg suggest replacing both with short. [1] If it helps you deal with the way the spec is written, you could pretend that acronym and abbr were both merged into one element short, and that that element was later renamed abbr... The idea was a relief because it made the tag MUCH more generic and (now that I think about it) could have more accurate and broader references (e.g. microformats use abbr for shorter date format, but short would make more sense). We have time for that now. (The rest of the e-mail will be handled along with other object feedback.) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson wrote: Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. Yes, Ogg most certainly is a choice. Every time you deny this, you give more weight for Apple, Nokia, et al to through around. Stop. We do have the choice of saying that Ogg is the way forward, and that if Apple, Nokia, et al don't want to implement it, then they can choose to not be conformant to the new standard. In my mind, this outcome is *far* superior to using a patent encumbered codec, even if the patent holders grant a royalty free license on it since the Ogg family have had so much research done on them that the chances of submarine patents should be at least greatly reduced, if not eliminated. In short, I am absolutely sick and tired of big companies coming in and throwing their weight around in standards organizations and getting their end-user-screwing technologies embedded into supposedly open and free standards. I've watched it happen in the past with the w3c, I've watched it happen repeated in the IETF, I don't think I've ever seen it *not* happen with ISO, ECMA seems *designed* to rubber stamp end-user-screwing technologies. And, yes, Apple, I'm looking at you here too. Your hands are not clean in this from past exercises. No, I don't trust you, yes, I'm going to object loud and long to any move that appears to be moving away from free and open technologies, which is what this is. Yes, I'm pissed. I'm taking an extreme position, but its a position of principle, and I will not back down from it. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson wrote: At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Not for companies that have already taken the risk of one of the codecs already. And this is exactly the way that Apple, Nokia, et al are hijacking this process. They throw out some nebulous business reason for why they don't want to use Ogg et al, and it gets bought, hook line and sinker. Maybe there is some legitimacy to that argument, even, but, I really don't care. The w3c should be about making the best free and open standard they can, and right now that means Ogg...if Apple and Nokia don't want to implement that, then that's their problem. If HTML5 doesn't get traction as a result, then you point at Apple and friends and point out that they refuse to implement a perfectly good and easily implementable spec and let the marketplace figure it out. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. Then you've decided to allow any big company to torpedo this process based on some nebulous claims of business risk. So much for the w3c being relevant. I thought the w3c stood for more than this. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. We have been told that Theora is not something everyone can implement. And that's a bald faced lie. Everyone *can* implement it, though they may choose not to. No way should the w3c be held hostage to that. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process so far. The language was changed because the big companies weren't comfortable with it, moving in the direction of screwing the little guy. That is bias. I'm sorry you believe that. It really isn't supposed to be. We're trying to find a solution that works for everyone. Then revert the text, even if only as a show of good faith. If you really want this to be a baseline codec that everyone can implement, revert the text and then change it to MUST. Making it a MUST doesn't make it possible for everyone to implement. If only standards development worked that way! It would be far easier. No, what makes it possible for everyone to implement is that its a free and open codec without encumbrances. Making it a MUST in the spec encourages people to implement and allows the market to bring more pressure to bear on it. This is a Good Thing(tm). and that is not an additional submarine patent risk for large companies. You've created the bias in the premise. By including the word additional, there, you have artificially limited the field to codecs which are already implemented by the large companies. That is not progress, that is one great big, huge, gigantic step backward. We have to take into accounts the needs of everyone. This includes large companies. If large companies will only accept codecs that they've already implemented, then that may have to be one of the criteria. That is absurd in the extreme. Its a new spec, any new spec involves new risk. If you aren't willing to take on new risk then HTML5 becomes nothing more than an XSLT transform away from HTML4. But since we're in a standards setting venue, non-standards-compliant browsers (now or future) and, by definition out of scope. Actually, all browsers are in scope to the WHATWG work. It would be short sighted in the extreme, for instance, to ignore IE, since they have a controlling position in the market. That just doesn't make any sense. If a browser decides that its not going to be standards compliant, then there's nothing that the standards body can do to affect what that browser does. The hope with IE is that MS at least makes noises about making IE standards compliant, and with IE7 at least made it less badly broken with respect to standards. I'll give them the benefit of the doubt and say that they're at lesat trying. If a browser maker isn't even going to try, then we can't worry about them. Ogg is _a_ choice, which provides freedom for some but not everyone. We need a codec that works for everyone. Then you might as well give up on HTML5 right now. I hope we can find a solution that doesn't involve giving up. :-) If you continue to let the big companies hijack the process like you have on this issue, then there's no hope. On Tue, 11 Dec 2007, Jeff McAdams wrote: A decision
Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, Jeff McAdams wrote: Ian Hickson wrote: Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. Yes, Ogg most certainly is a choice. Every time you deny this, you give more weight for Apple, Nokia, et al to through around. Stop. This isn't a matter of different browser vendors having different weight. What we are looking for here is a solution that addresses the needs of every browser vendor. Ignoring some of the browser vendors isn't an option, whether those browser vendors are Apple and Nokia, or whether they are Opera and Mozilla. We do have the choice of saying that Ogg is the way forward, and that if Apple, Nokia, et al don't want to implement it, then they can choose to not be conformant to the new standard. Our goal here is not to be able to point to browsers and label them as compliant or non-compliant. Our goal is to be able to use video on the Web in a royalty-free manner in a way that interoperably works in _every_ browser, whether from Apple, or Opera, or Mozilla, or Microsoft, or Nokia, or whoever. In my mind, this outcome is *far* superior to using a patent encumbered codec, even if the patent holders grant a royalty free license on it since the Ogg family have had so much research done on them that the chances of submarine patents should be at least greatly reduced, if not eliminated. Ogg Theora has not had an exhaustive patent search (you may be thinking of Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_ exhaustive patent search than Ogg Theora. If H.264 Baseline was made available royalty-free, why would we _not_ want to use it instead of Ogg Theora? It is technically a far superior codec, it has the same or lower risk of submarine patents, and it would have (by definition given the context within which I am asking the question) the same licensing as Ogg Theora. In short, I am absolutely sick and tired of big companies coming in and throwing their weight around in standards organizations and getting their end-user-screwing technologies embedded into supposedly open and free standards. I understand, but I assure you that that is actually not what is happening here. We are in fact trying to find a solution that doesn't involve screwing over end users. I am sorry if you find it hard to believe that we actually care about end users. And, yes, Apple, I'm looking at you here too. Your hands are not clean in this from past exercises. No, I don't trust you, yes, I'm going to object loud and long to any move that appears to be moving away from free and open technologies, which is what this is. Yes, I'm pissed. I'm taking an extreme position, but its a position of principle, and I will not back down from it. That is your right, but please, when posting to the WHATWG list, keep your tone moderated and your arguments rational. Accusing other participants of being untrustworthy does not help us come to an amicable and acceptable solution, it just antagonises people and makes them less willing to compromise, something which could be fatal in this issue. Dismissing Apple's concerns doesn't help us address Apple's concerns. Apple are not dismissing our requests for a royalty-free codec, we should not dismiss their requests for a codec that doesn't involve unwarranted risks of potentially extremely expensive legal action against them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)
Ian Hickson [EMAIL PROTECTED] wrote: There is no way we can ever guarantee that there are no covering patents. Whether a patent covers a technology or not really has more to do with what the courts say than with what the patents say. If Apple say they don't want to implement Ogg, then we have to find another solution. (Similarly -- Opera, Mozilla, et al, don't want to implement H.264. So we have to find a solution other than H.264.) Is there any codec that would satisfy everybody? I doubt it, to be honest. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)
On Wed, 12 Dec 2007, Stewart Brodie wrote: Ian Hickson [EMAIL PROTECTED] wrote: There is no way we can ever guarantee that there are no covering patents. Whether a patent covers a technology or not really has more to do with what the courts say than with what the patents say. If Apple say they don't want to implement Ogg, then we have to find another solution. (Similarly -- Opera, Mozilla, et al, don't want to implement H.264. So we have to find a solution other than H.264.) Is there any codec that would satisfy everybody? I doubt it, to be honest. Currently there are no known codecs that satisfy everyone; if there were, we'd have picked it and moved on by now. However, that could change; there are people investigating this as we speak. (Indeed there's a whole conference about this and related issues this week in San Jose.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, Jeff McAdams wrote: And this is exactly the way that Apple, Nokia, et al are hijacking this process. They throw out some nebulous business reason for why they don't want to use Ogg et al, and it gets bought, hook line and sinker. Maybe there is some legitimacy to that argument, even, but, I really don't care. Indeed, the actual argument doesn't really matter. The key take-away is that Apple and Nokia don't want to implement Ogg Theora, so, since our goal is full interoperability between all browsers, we can't use Ogg Theora as our common codec. The change in the spec is merely to reflect this. The w3c should be about making the best free and open standard they can, and right now that means Ogg...if Apple and Nokia don't want to implement that, then that's their problem. It actually is our problem too, as it would lead to HTML5's video element being a failure. If HTML5 doesn't get traction as a result, then you point at Apple and friends and point out that they refuse to implement a perfectly good and easily implementable spec and let the marketplace figure it out. The marketplace is likely to figure it out by doing what they've been doing all this time, namely, use Flash (which is moving to H.264). This is a losing proposition if you desire the Web to be based on royalty free standards as I do. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. Then you've decided to allow any big company to torpedo this process based on some nebulous claims of business risk. That is indeed the case, just like we allow small companies to torpedo the process based on some nebulous claims of excessive license fees. That's how standards development works. So much for the w3c being relevant. I thought the w3c stood for more than this. This is the WHATWG, not the W3C. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. We have been told that Theora is not something everyone can implement. And that's a bald faced lie. Everyone *can* implement it, though they may choose not to. Ok, we have been told that Theora is not something everyone will implement. The net result is the same. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process so far. The language was changed because the big companies weren't comfortable with it, moving in the direction of screwing the little guy. That is bias. I'm sorry you believe that. It really isn't supposed to be. We're trying to find a solution that works for everyone. Then revert the text, even if only as a show of good faith. Reverting the text doesn't find a solution that works for everyone -- it merely puts forward a solution that we _know_ isn't acceptable to everyone as a fait accompli, which is, as you so finely put it, a bald-faced lie. Actually, all browsers are in scope to the WHATWG work. It would be short sighted in the extreme, for instance, to ignore IE, since they have a controlling position in the market. That just doesn't make any sense. If a browser decides that its not going to be standards compliant, then there's nothing that the standards body can do to affect what that browser does. If the vendor decides to not be standards compliant on principle, then yes, I agree. And such vendors would be ignored. However, Apple has repeatedly shown a true desire to follow standards (e.g. they were the first browser vendor to fix the bugs that the Acid2 test exposed in their rendering engine), and we owe it to them to address their concerns so that they _can_ be compliant. Whatever solution we find will be one that is royalty free and open. That is not in any doubt. Then as a show of good faith, revert the text until the discussion happens. I don't understand how my statement leads to yours. They seem to be non-sequitur. How does having the spec recommend something that we know isn't acceptable to everyone, a show of good faith? As the person who would make that decision, I assure you that no decision has in fact been made. That is, in fact, the entire crux of the issue. But the fact is that the text was changed away from specifying free and open codecs, even if as a default position. And that's offensive. The text went away from specifying a _particular_ free and open codec without the consensus of the group as a whole, to specifying that we need a free and open codec that _does_ have consensus. I do not understand why that would be
[whatwg] So called pre-exising use by large companies
From what I read, it is argued, that pre-existing use by large companies is a good indication of less risk for submarine patents. It is also argued, that Theora has not much pre-exsting use by large companies, and among others, H.264 does. Is this really true? I have a hard time believing that no large companies shipped Theora decoder ever. And how large is large? I would appreciate any information on this matter. -- Seo Sanghyeon
[whatwg] What to say about cite (was: Re: Joe Clark's Criticisms of the WHATWG and HTML 5)
On Dec 11, 2007, at 12:53, Ian Hickson wrote: I am still on the fence about using cite in my thesis. Currently I am using it to mark up titles of works. Any advice as to what the specshould say on the matter is welcome; in fact I have a whole folder of such advice that I'll be addressing in due course. * Considering that mere presentation-level implementation in visual UAs is ubiquitous and needed for Support Existing Content, UAs will have to continue to italicize cite. * Considering that content authored to HTML 4 may be syndicated or otherwise repurposed into an HTML5 site template, it doesn't seem productive to require the removal of cite from such content. Hence, cite should probably be kept as conforming part of the language. * Considering the default presentation of cite since the dawn of time, the example in the ancient IIIR draft and DanC's IRC statement[1] about the original intent, I think the element should be defined [at least primarily] as meaning title-of-work. See §7.133 on page 284 of CMOS 14th ed. * Considering the misguided over-general definition in HTML 4, the definition in HTML5 should probably contain some weasel words to allow those who read the HTML 4 definition to use cite for personal names without getting into flame wars. * Considering that during the existence of cite in some form in HTML, no compelling semantic mining use cases have emerged where the semantics miner and the document author weren't in tight collaboration (or the same person as in the famous diveintomark.org case) and considering that the default presentation of cite is biased towards publishing styles close to that documented in CMOS, I think the spec should be worded not to require titles of works to be marked up as cite. Specifically, the spec should say something that'd protect authors who don't mark titles of works as cite (for whatever reason; tool support, i18n considerations, whatever) from time-wasting flamewars. (I could not come up with any good story explaining why my mother as a page authors should make an effort to use cite instead of whatever command-i produces in Dreamweaver.) So that leaves that spec should say that cite is part of the language. If it helps the styling goals of the author, it's OK to mark up titles of works as cite, but it is OK not to mark up titles of works as cite. Plus some weasel words that effectively allow markup up names of people as cite but doesn't suggest that authors do so. Let's see what spec text could look like: The cite element represents a title of work. Sometimes it is used for personal names. The use of the cite element is optional: titles of works (and personal names) may be communicated without any particular markup or may be marked up as i or b in order to adhere to a house style that requires italicization or bolding. (The personal name weaseling part is not particularly good. I have a hard time figuring out how to deal with the HTML4 semantic legacy here.) [1] http://krijnhoetmer.nl/irc-logs/html-wg/20070607#l-797 -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson schrieb: Ogg Theora has not had an exhaustive patent search (you may be thinking of Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_ exhaustive patent search than Ogg Theora. Well, thanks to VP3 having been a commercial product licensed to numerous commercial entities (e.g. Nullsoft/AOL) the very existance of On2 depended on being clean of patents they don't own. The statement that Theora had no exhaustive patent search is in danger of being inaccurate. Plus as long as no meaningful metric exists defining how exhaustive a patent search has been things are a bit hard to compare anyway. Now, thanks to the commonly accepted ( ;-) ) fact that Vorbis has had an exhaustive patent search: Does that mean that Vorbis is a candidate for a baseline audio codec? Or is the actual extend of any patent search irrelevant? If so: Why is the H.264 patent search relevant? If an exhaustive patent search is a key towards acceptance of any format: Why not commision one? If H.264 Baseline was made available royalty-free, why would we _not_ want to use it instead of Ogg Theora? It is technically a far superior codec, it has the same or lower risk of submarine patents, and it would have (by definition given the context within which I am asking the question) the same licensing as Ogg Theora. I'd say the opposite could just as well apply. H.264 is a sophisticated codec using plenty of state-of-the-art technologies. Thus H.264 may be a much bigger target to submarines than Theora, which quite frankly is a pretty straight-forward coding scheme using well-known concepts without sophisticated bells and whistles. That way or another: Plainly saying that one codec is at higher risk than the other is a rather dangerous adventure.
Re: [whatwg] Removal of Ogg is *preposterous*
David Hyatt wrote: Fear of submarine patents is only one reason Apple is not interested in Theora. There are several other reasons. H.264 is a technically superior solution to Theora. Ignoring IP issues, there would be no reason to pick Theora over H.264. Everyone wants an open freely implementable codec, but it doesn't follow that Theora should automatically be that codec. About the only argument I've heard in favor of Theora is that it's open, but that is an argument based purely on IP and not on technical merits. Openness is a prerequisite. Technical adequacy is a prerequisite. The technically best solution is not a prerequisite. In case it isn't obvious yet, an open, adequate format is preferred over a better proprietary one. If you consider mobile devices that want to browse the Web, then depending on the constraints of the device, a hardware solution may be required to view video with any kind of reasonable performance. A mandate of Theora is effectively dictating to those mobile vendors that they have to create custom hardware that can play back Theora video. Given that such devices may already need a hardware solution for existing video like H.264, it seems unreasonable for HTML5 to mandate what hardware a vendor has to develop just to browse Web video on a mobile device. Thanks. I wasn't previously convinced we needed to mandate *any* particular format, but you just convinced me. If hardware is support is required for some devices, then it does indeed sound like a good idea to mandate some minimum level of conformance. It is far better that this minimum level of conformance be an open, freely implementable standard such as Ogg/Theora than a known patent encumbered format such as H.264. Or put another way, imagine that GIF was an open format but PNG was IP-encumbered. Would you really want to limit the Web to displaying only GIFs just because it was the only open image format available? Please stop attacking straw men. No one has suggested that. Under those circumstances, I absolutely would support requiring all browsers to display GIFs. This would not prohibit them from also displaying PNGs if they chose to license the relevant patents. Technical arguments are relevant here, so take some time to consider them before accusing people of having shady ulterior motives. Technical arguments are relevant, but do not control. They are neither the only nor the most important consideration. Furthermore, when apparently intelligent people persist in making simple logical and rhetorical errors, it is difficult not to infer that an ulterior motive may be present. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Ogg Theora vs H.264
Ian Hickson wrote: On Wed, 12 Dec 2007, Jeff McAdams wrote: Ian Hickson wrote: Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. Yes, Ogg most certainly is a choice. Every time you deny this, you give more weight for Apple, Nokia, et al to through around. Stop. This isn't a matter of different browser vendors having different weight. What we are looking for here is a solution that addresses the needs of every browser vendor. Ignoring some of the browser vendors isn't an option, whether those browser vendors are Apple and Nokia, or whether they are Opera and Mozilla. A commercial entity may opt to pay royalty for every product they distribute. A non-commercial entity that distributes a free-as-in-beer product cannot do that. Nokia or Apple are able to use some codecs that Mozilla cannot. You cannot change the fact. If H.264 Baseline was made available royalty-free, why would we _not_ want to use it instead of Ogg Theora? IF H.264 was made available royalty-free, THEN I'd agree that it should be used instead of Ogg Theora. It is a better codec except for the IP/licensing issues. However, right now Ogg Theora is the royalty-free option that IS AVAILABLE. I'd suggest putting the Ogg Theora as the baseline for now and be prepared to change it to H.264 if and only if that were made available before the specification is done. I wouldn't count on it, though. As for the submarine patents: by the very definition of submarine patent, you cannot know if one exists for H.264 or Theora so I wouldn't try to use that as an argument for either one. If you're too afraid to set the baseline to Theora because of possible submarine patents, you cannot set it to any other codec either! (It's possible that even some of the aged codecs have new submarine patents because the patent offices are that good...) I believe that the baseline codec should be specified. -- Mikko signature.asc Description: OpenPGP digital signature
[whatwg] arrggghhh (or was it ogg)
I apologize in advance if this question has already been broached. In what I have seen of several of the ogg threads, I seem to see the question being danced around, but not directly addressed. Part one of the question: What guarantees do Apple, Nokia, et. al. offer that their corporate-blessed containers/formats/codecs are free from threat for (ergo) the rest of us? Are they willing to make binding agreements to go to bat for _us_ in court? Part two of the question: Where does anyone expect to find any software technology that can't be submarined (post-facto, really) sufficiently to incur more court costs than most of us independent (read, one-man semi-hobbiests, trying to make useful tools for problems the big guys are too big to see) developers can afford to even hire a lawyer to officially say, I'm sorry for even daring to think for myself and I promise never to do it again! Yeah, bring up that stupid EOLAS business. While I appreciate the greatest software polluters in the industry getting a bite taking out of their bottom line, I don't appreciate that it validates (not legally, but in practice) the practice of using the absurdity of patenting literature^H^H^H^H^H^H^H^H^H^H software as a weapon for waging wars in the marketplace. It validates the devil's game when you use the devil's tools. You look closely at what happened in EOLAS (and what is happening on several other fronts) and it is simple. Somebody gets a patent vaguely related to something someone they want to attack is doing and sics the lawyers on them, and the lawyers try to figure out a way to be enough nuisance to induce a settlement. We all know that is what happens. We all know there is no way to defend against it. No patent search can be sufficient. So Nokia and Apple and whoever else are simply trying to push the standard to the solution they have agreed to in their back-room deals, and they want w3c to support their back-room deals. Thus my question: Who fights for the little guys if the big guys are warning^H^H^H^H^H^H^H telling us that the little guys' solution is going to get attacked? What good does it do to use what they tell us they want? We know they are planning attacks anyway, just because they've done this. Long rant. I hope I'm made some sense. joudanzuki Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)
On Dec 12, 2007 1:07 AM, Ian Hickson [EMAIL PROTECTED] wrote: what the courts say than with what the patents say. If Apple say they don't want to implement Ogg, then we have to find another solution. (Similarly -- Opera, Mozilla, et al, don't want to implement H.264. So we have to find a solution other than H.264.) Thank you for your reply. From what you just said, I'm afraid we're stuck between a rock and a hard place, and would not be able to resolve it. This is really too bad. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: [whatwg] several messages regarding Ogg in HTML5
Ian, are you saying that not implementing a SHOULD statement in the spec would make a browser non-compliant with HTML5? Are you saying that if a vendor does not implement the OPTIONAL Ogg support then they would not use HTML5 at all? I'm not being sarcastic here. I'd actually like you to answer these points to understand your position on the SHOULD statement. I commend you for trying to support all views but you yourself have indicated that the Ogg vs. H.264 parties cannot agree - and in the absence of an improbable event (the spontaneous appearance of an unencumbered, court tested, high-performance, non-proprietary video codec) never will. Even if Ogg were court-tested Nokia and Microsoft will never change their position while remaining in the MPEG-LA consortium. The only other option then is inaction (your apparent solution) - which we ALL agree will hand the win to Macromedia (97% Flash market share). One of these parties must get their way, and currently the majority of voiced opinion here is that we SHOULD recommend Ogg (as in SHOULD not MUST). As others have said, if Apple and Nokia (the minority of respondents) do want to implement Ogg then there appears to me to be no requirement for them to do so while retaining compliance. There is nothing I see that prevents video being used with other formats. Surely this will not destroy the video element, it will simply require Safari, IE and Nokia users to download a plugin for some sites (which open-source groups will be happy to provide) or use an Ogg compatible browser or 3rd-party app. There is no logical reason we should not *recommend* Ogg while no better options remain. It isn't perfect but it is the best nonetheless. If nothing else it will give the public (this is still a public spec isn't it?) a baseline format for the publishing of non-profit materials that can be decoded by all Internet users (yes, even those on Mac) without restriction. Submarine patents are irrelevent here as we all agree there there is no viable solution for that and there isn't likely to be within the useful lifetime of this specification. As it stands, right now, h.264 is patent-locked, VC1 is patent-locked, Flash is patent-locked, h.261 is too slow, Dirac isn't ready. Ogg is reasonably fast, well tested, well support and NOT patent-locked until somebody proves otherwise. It is not unreasonable to tell browsers they SHOULD support it, even though we know some won't. Apple; How can we make you happy without committing to future h.264 royalties? More specifically, what other royalty-free, non-patented, drm-supporting codec would you prefer? Microsoft/Nokia; Are you even going to support HTML5, when you seem so keen on making your own standards? When have you EVER been fully compliant with a public spec? Ian; Why do you think we are angry with you? What will it take to get this (apparently unilateral) change revoked? Finally, what is Google/YouTube's official position on this? I know that's a lot of questions but I feel they SHOULD be answered rather than simply attacking the Ogg format. Shannon
Re: [whatwg] Removal of Ogg is *preposterous* , SHOULD, and other matters
On Tue, 11 Dec 2007, L. David Baron wrote: In this case, most implementors following the SHOULD and implementing Theora might help companies whose concern is submarine patents become more comfortable about shipping Theora, especially if some of the implementors are companies similar in size or wealth to those non-implementors. Hixie replied: As it stands, all the vendors who would implement Theora due to the SHOULD in the spec already are implementing Theora. David's note got me to wondering if inclusion of the SHOULD language by the W3C might ultimately reduce the liability to companies who actually implement Theora. That is, a judge who discovered that the W3C acted in good faith in attempting to find an unencumbered codec when it in turn recommended to Big Company A that it should use Theora might be quite receptive to A's defense against Scavenger S's claim against A. I don't know if patent law (like copyright law, at least in the US) makes allowances for innocent infringement, but if it did that would certainly lend some protection to both W3C and those who might follow its advice. This would be a question for the attorneys who I gather will ultimately be called in to help the W3C WG with its deliberations. Another question of a similar nature: while I understand that Big Company A might indeed extend its vulnerability by actually conducting patent searches (various aspects of law seem to be likewise counter-intuitive, even paradoxical), would that remain true if Big Companies A, B and C were to underwrite a large-scale patent search by W3C? W3C might be able to shield the sponsoring companies from whatever incidental discoveries it made midst its deep search and hence limit their liability. Re-iterating some things I said earlier, either there is wiggle room remaining to create a new video (or audio) formats in the gaps between existing patents or there isn't. It seems unlikely that all available space has been carved out particularly given that JPEG and GIF87 are already out there and given the requirement that a patent be nonobvious. Conceptualizing sequences of video frames as a time-based spatial frequencies analysis seems obvious. From there it would seem that almost infinitely many data compression schemes exist. For example, one ordinarily would tend to match the redundancies of frame i with those at allied locations in frame i+1. Suppose we consider an arbitrary frame to be a clipped rectangular subregion of a larger realm over which the camera actually moves. Then the compression technique might consist of first building hypotheses about the larger realm and then calculating interframe redundancy based on those hypotheses. With sound we have strings (of sinusoidal amplitudes) being concatenated together in each discrete moment in time; string similarites across moments maybe recast as multidimensional substring problems hence transforming what might look at first like a conventional Fourier analysis into something based more on discrete mathematics in very high dimensional space. I guess all I'm saying is that the number of methodologies that could be applied to the problems seems large and that one outcome that should not be foreclosed is the development of an obvious (hence non-patentable) codec from scratch with the collective talents of those so inclined to cooperate. If each step in the production of such a format is obvious, then all of its components would, by definition, be patent free. If no such wiggle room exists then the granters of those patents have arguably been overzealous and at least some of those patents must, it seems, be invalid. Something that is suggested to me in the arena of international treaty work on IP harmonization that the W3C may be interested in adding its voice to would be large scale indemnification -- WIPO working in conjunction with W3C or some such thing. Certainly, reform of patent law is apparently mandated, though doing such work on a country-by-country basis seems like slow work. In the world of Real Property, the common law concept of eminent domain or compulsory purchase is extended as a power to governments to allow for creation of technologies (like roads or utilities) that would otherwise be encumbered by known molecular obstacles (like barns or fast food restaurants). When those obstacles become invisible and non-molecular (in the world of IP) and when they fail to have coordinates in Euclidean space, the regional jurisdiction of the government seems ill-suited to deal with those obstacles. Creating a treaty which allows the W3C to condemn a patent that I might hold might give a bit too much power to some folks (and I can imagine a zillion folks, and twice that many bots, voting against such a treaty) but in the long run. it might be necessary to think such thoughts in order to allow interoperability on our info-highways. cheers, David Dailey
Re: [whatwg] Proposal for New Tag for UI Elements
2007/12/11, Krzysztof Żelechowski: The + sign does not belong to the user input, it is a shortcut the following explanation: OL LI press KBD Shift/KBD LI press KBD F3/KBD LI releaseKBD F3/KBD LI releaseKBD Shift/KBD /OL (That is how I have to explain it to my mom; otherwise she always gets it wrong.) So the + sign is actually misleading and certainly does not belong to the KBD tag. Think about printed instructions that show the keys boxed. Would you want to get the + sign boxed as well? Only kbd inside kbd would be boxed then, so the + sign is not a problem: pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd (hold kbdShift/kbd down while pressing kbdF3/kbd, then release both keys, in any order)/kbd./p Or eventually: pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd/kbd (i.e. hold kbdkbdShift/kbd/kbd down while pressing kbdkbdF3/kbd/kbd, then release both keys, in any order)./p -- Thomas Broyer
Re: [whatwg] Asynchronous database API feedback
2007/12/11, Krzysztof Żelechowski: Allowing the script to wait until the transaction completes would be enough to provide synchronization, wouldn't it? A stubborn programmer can still do it: make a transaction set an event upon completion and make the script loop until that event is set. Upon the theory that the transaction in question is a quickie, it would be quite acceptable, especially if the script engine fiddled with thread priorities a bit. If I am right, it is not such a big issue after all. It'd only work in a multi-thread environment; otherwise, script might be executed synchronously in response to user-input triggered events. For example, I played a bit with PalmOS programming a few years ago (before they release the Tungsten series). At that time (might have changed since then), there were only two threads: one to receive and queue user-input events and the other where your code was running (with an event loop to consume pending events). In these conditions, simulating a synchronous API with an asynchronous one (might happen: send data over the network and having an event back for the response) and a loop don't work, your loop has to be your event loop, where you would queue back every event that's not telling you your asynchronous call has returned. -- Thomas Broyer
[whatwg] Ogg content on the Web
FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. wikipedia.org is something like #8 in the world at present, so this is set to be a significant content repository actually used by people. A video tag which can be relied upon to support the format in at least Firefox would be enormously helpful to us and our readers. So far we have had zero patent trolls come calling. I wonder why that is. [note: There was a recent press release about Ogg support in HTML5 which we didn't get it together to be mentioned in. Any further on these, please cc me directly at [EMAIL PROTECTED] and I'll make sure it happens myself.] - d.
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 12, 2007 4:08 PM, Manuel Amador (Rudd-O) [EMAIL PROTECTED] wrote: El Mié 12 Dic 2007, Robert Sayre escribió: On Dec 11, 2007 6:51 PM, David Hyatt [EMAIL PROTECTED] wrote: SHOULD is toothless. Spefications aren't laws. MUSTs are toothless as well. It carries absolutely no weight. I don't think it's appropriate for such weak language to be in the HTML5 spec. It should either be a MUST (which is inappropriate at this juncture for reasons that Dave Singer. Ian Hickson and myself have posted about in previous messages) or just not be mentioned at all. It isn't weak language. It places the blame squarely on the party who fails to meet the requirement. Agreed with you, Robert. If SHOULD carries absolutely no weight... then why don't we just leave the paragraph there? Stop eluding this question. I disagree. If somebody is implementing the spec and are looking for a recommendation of the W3C for which video codec to use, the SHOULD has a large effect. If there is no codec mentioned, they will go looking for what others have implemented and start a complicated decision process with an uncontrollable outcome. If a SHOULD clause, i.e. a recommendation, is all we can agree on, then it is better than not mentioning a codec at all. I was happy with the previous formulation of the paragraph and I am happy to go through a technical assessment of the existing codecs wrt the criteria that Ian has written into the spec right now. I am sure we will come to the same conclusion that we did before and Ogg Theora/Vorbis will be written back into the spec as a recommendation, but this time around it will be stronger because we have done an assessment of its merits and decided that they are the only ones coming even close to fulfilling the needs. I have no issues with this process. Regards, Silvia.
Re: [whatwg] So called pre-exising use by large companies
Here's a rundown of the major media players and their support: Windows Media - Requires third party pluginhttp://www.illiminable.com/ogg/ Quicktime 7 - Requires Xiph.org plugin http://xiph.org/quicktime/ Real Player - Requires Helix pluginhttps://helixcommunity.org/frs/?group_id=7 In effect, no major media player supports Theora out of the box. It's interesting to note that MPEG, H.263, and MPEG4/H.264 are far more standard across media players. Which, I think, means that the spec should recommend support for these formats. However, a variety of good points were raised in a thread a few months back. What you effectively have here is if you choose a free format that anyone can implement, you alienate the commercial implementations due to their due-diligence fears. (Which, as an aside, are justified when it comes to media technology. This stuff is so mired in patents, it isn't even funny. H.263 was intended to be an open spec that anyone could implement at no cost. It didn't take long for patents to start coming out of the woodwork and effectively close the format off.) On the other hand, if you choose commercially supported formats like MPEG/MPEG4, you run into the issue that the free software camp is afraid of being unable to produce a GPL-compliant version FFMPEG exists, but distros are not legally able to ship it. The user has to download and install it after the fact, in a psuedo-legal workaround. Both sides argue that users can download a simple plugin which will make either possible standard work. Which is true, but it ignores the fact that Flash ships with the H.263 codec by default and is kicking everyone's sorry asses in the online video space. As long as Flash has a consistent video format that everyone can use and HTML 5 doesn't, Flash is going to be the defacto standard. I don't think there are any easy answers here. About the best solution I can come up with is to provide browser detection of media formats. That way web developers can do a runtime test for a media format and tell the user Hey, you need to install a plugin if the format chosen by the website is not available. Since the vast majority of computers have MPEG4 support, that will likely become the resulting standard like JPGs and GIFs. If enough people push long enough and hard enough for Theora, it will become a new standard alongside these existing formats, much like PNG. Especially if a few major web browsers ship Theora support long enough to assuage fears over its unknown patent status. Thanks, Jerason Banes On Dec 12, 2007 6:00 AM, Sanghyeon Seo [EMAIL PROTECTED] wrote: From what I read, it is argued, that pre-existing use by large companies is a good indication of less risk for submarine patents. It is also argued, that Theora has not much pre-exsting use by large companies, and among others, H.264 does. Is this really true? I have a hard time believing that no large companies shipped Theora decoder ever. And how large is large? I would appreciate any information on this matter. -- Seo Sanghyeon
Re: [whatwg] arrggghhh (or was it ogg)
If by Corporate Blessed, you mean codecs like H.264, there's a very simple answer to that. Nokia and Apple pay licensing fees to a company called MPEG LA. MPEG LA indemnifies Nokia and Apple from patent lawsuits over the use of MPEG-related codecs. Should anyone come forward with a new patent, the MPEG LA will litigate the matter and/or come to an agreement with the patent holder to license the patent on behalf of their member companies. http://en.wikipedia.org/wiki/H.264#Patent_licensing Thanks, Jerason Banes On Dec 12, 2007 7:15 AM, Joseph Daniel Zukiger [EMAIL PROTECTED] wrote: What guarantees do Apple, Nokia, et. al. offer that their corporate-blessed containers/formats/codecs are free from threat for (ergo) the rest of us? Are they willing to make binding agreements to go to bat for _us_ in court?
Re: [whatwg] several messages regarding Ogg in HTML5
(I've been watching the emails fly around with great interest, but there has been a rather significant volume. You'll have to forgive me if the following question has already been answered.) It seems to me that the argument keeps coming back to the fact that H.264/AAC has patent protection available while Theora/Vorbis does not. Thanks to the efforts of the MPEG-LA, Nokia, Apple, and even Microsoft can sleep well at night. However, this raises a question in my mind. MPEG-LA is the administrator of a variety of patent portfolios. Not just the MPEG sphere of patents, but also IEEE 1394 and DVB-T. They are also working to add patent portfolios for VC-1, ATSC, DVB-H, and Bluray. Which means that they are well-equipped to provide patent administration and indemnification for a wide variety of formats. *Has anyone asked MPEG-LA if they'd be willing to provide indemnification for Vorbis/Theora?* While I understand that there is no actual patents to license at this time, a fee to MPEG-LA (enough to cover possible patents in the future + MPEG-LA's standard profit margin) for protection against submarine patents could very well solve this impasse. Any thoughts? Jerason Banes On Dec 11, 2007 3:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling.
Re: [whatwg] Asynchronous database API feedback
Dnia 11-12-2007, Wt o godzinie 11:22 -0800, Aaron Boodman pisze:
With an asynchronous API, it gets quite a bit messier. Here's an
example of what it might look like:
var messages = incoming_data;
db.transaction(function(tx) {
processNextMessage(tx);
});
function processNextMessage(tx) {
if (!messages.length) return;
tx.executeSql(insert into messages (id, subject, body) values (?, ?, ?), [
}
Please, it is only a matter of programming style. You can get used to
it, really. I actually prefer the code above to a synchronous one.
Chris
Re: [whatwg] Video codec requirements changed
On 12 Dec 2007, at 01:41, Maciej Stachowiak wrote: 1) maybe (I've heard game vendors cited, not sure which ones) I know someone already posted a list, but it is used within all Unreal Engine 2.5 (i.e., UT 2004) and Unreal Engine 3 (i.e., UT 3) games (which I'm sure you can find a long list of games that use them on Wikipedia or elsewhere). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Ogg content on the Web
On Dec 12, 2007, at 6:23 AM, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. wikipedia.org is something like #8 in the world at present, so this is set to be a significant content repository actually used by people. A video tag which can be relied upon to support the format in at least Firefox would be enormously helpful to us and our readers. So far we have had zero patent trolls come calling. I wonder why that is. Because the Wikimedia Foundation doesn't have much money. Patent trolls are opportunistic, not idealistic. -ryan
Re: [whatwg] Ogg content on the Web
On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? So far we have had zero patent trolls come calling. I wonder why that is. Do you have enough money to pay a fine a similar size to what MS got last year? If you don't have enough money, they won't sue you. It isn't worth their time. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? Er, what are the others? - d.
Re: [whatwg] Video codec requirements changed [ISSUE-7 video-codecs]
Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. http://www.whatwg.org/issues/#graphics-video-codec Thanks for letting us know. This message connects the email discussion to the issue tracker... http://www.w3.org/html/wg/tracker/issues/7 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Re: [whatwg] The truth about Nokias claims
On Wed, 12 Dec 2007 02:01:34 +0100, Shannon [EMAIL PROTECTED] wrote: Microsoft: Heavy investment in WMV and DRM. 'Essential patent holder' in H.264. Major shareholder in Apple On 12/12/2007, Arve Bersvendsen [EMAIL PROTECTED] wrote: I believe Microsoft sold off their Apple stock years ago. Yes. At a considerable profit, one might add. -- David liorean Andersson
Re: [whatwg] Ogg content on the Web
On 12 Dec 2007, at 17:44, David Gerard wrote: On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? Er, what are the others? Technically speaking, Theora is actually unencumbered (it just has a RF license covering the patents from On2). Dirac is in a similar situation. Apart from those two, the others I can think of are those that are in excess of twenty years old (and therefore their patents have expired), such as H.260. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Asynchronous database API feedback
I think the issue you're forgetting is when opening a transaction can
fail. The transaction callback is only called when the transaction is
successfully opened and you know that it is starting out valid.
~Brady
On Dec 12, 2007, at 9:37 AM, Dimitri Glazkov wrote:
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx = db.createTransaction();
tx.add(db.sql('create table if not exists chickadees(name text, kind
text)'));
tx.add(db.sql('insert into chickadees values(?, ?)', ['moesha',
'black-capped']));
tx.add(db.sql('select * from chickadees', [], function(rs) {
console.log(rs.rows.name); }));
tx.execute(function(error) {
console.log('bird flip!');
});
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [], function(rs) {
console.log(rs.rows.count); }).execute();
What do you think?
:DG
Re: [whatwg] whatwg Digest, Vol 33, Issue 90
On 29/12/2006, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Why would you need a plugin for code/ ? For the ability to distinguish the syntax and semantics of varying types of code, in a virtually infinite set of possible different syntaces and semantics. Currently, Web Applications 1.0 and XHTML 2 are both proceeding. Web Applications 1.0 has two serializations: an HTML serialization and a (slightly) richer XHTML serialization. Unfortunately, the current plan is for both XHTML 5 (as Web Applications 1.0's XHTML serialization is jocularly called) and XHTML 2 to use the same namespace, so they will have to be distinguished by their schemas instead. Their schemas are not present in the document. As such, user agents will have to assume one set of semantics over the other. Simply speaking, there can one be a single meaning of the XHTML namespace in a single user agent without jumping through an endless amount of hoops. And for XHTML5, that namespace must be the same as for XHTML 1.0. Changing the namespace is a no-go. So, if XHTML2 really wants to play in the browser space, it needs to either fall in line or change namespace. I personally suspect XHTML 2 development will continue. Web Applications 1.0's big strength, backwards compatibility, is simultaneously a weakness from which XHTML 2 need not suffer. Well, the lack of backwards compatibility coupled with the use of the same namespace makes XHTML5 and XHTML2 mutually exclusive. Like others also active on the www-html mailing list, I see no contradiction between expending effort on both drafts. As long as it's done under full knowledge and intention of XHTML2 not being used on the web, yes. If the goal of XHTML2 is to be usable on the web, it needs to keep the guarantees and semantics of XHTML1.0 and XHTML5, only ever doing changes by addition. Or, under a different namespace. -- David liorean Andersson
Re: [whatwg] Removal of Ogg is *preposterous*
Also as Maciej said earlier, we at Apple did not ask that the SHOULD wording be removed and had stated we could live with it. dave On Dec 12, 2007, at 1:12 PM, David Hyatt wrote: On Dec 12, 2007, at 6:38 AM, Elliotte Rusty Harold wrote: David Hyatt wrote: Fear of submarine patents is only one reason Apple is not interested in Theora. There are several other reasons. H.264 is a technically superior solution to Theora. Ignoring IP issues, there would be no reason to pick Theora over H.264. Everyone wants an open freely implementable codec, but it doesn't follow that Theora should automatically be that codec. About the only argument I've heard in favor of Theora is that it's open, but that is an argument based purely on IP and not on technical merits. Openness is a prerequisite. Technical adequacy is a prerequisite. The technically best solution is not a prerequisite. In case it isn't obvious yet, an open, adequate format is preferred over a better proprietary one. I don't think that is obvious at all, especially when the video tag's chief competition, Flash, is using the technically superior solution. Why would authors switch away from Flash if video doesn't offer any technically compelling reason to switch? If you consider mobile devices that want to browse the Web, then depending on the constraints of the device, a hardware solution may be required to view video with any kind of reasonable performance. A mandate of Theora is effectively dictating to those mobile vendors that they have to create custom hardware that can play back Theora video. Given that such devices may already need a hardware solution for existing video like H.264, it seems unreasonable for HTML5 to mandate what hardware a vendor has to develop just to browse Web video on a mobile device. Thanks. I wasn't previously convinced we needed to mandate *any* particular format, but you just convinced me. If hardware is support is required for some devices, then it does indeed sound like a good idea to mandate some minimum level of conformance. It is far better that this minimum level of conformance be an open, freely implementable standard such as Ogg/Theora than a known patent encumbered format such as H.264. Good. I also believe there should be a mandated baseline. That's why I think SHOULD is too weak, and that we should be working towards a MUST. Or put another way, imagine that GIF was an open format but PNG was IP-encumbered. Would you really want to limit the Web to displaying only GIFs just because it was the only open image format available? Please stop attacking straw men. No one has suggested that. Under those circumstances, I absolutely would support requiring all browsers to display GIFs. This would not prohibit them from also displaying PNGs if they chose to license the relevant patents. Right, but, continuing the analogy, the issue you run into is if the Web at large considers PNG to be superior and just ends up using it anyway, then specifying SHOULD use GIF is rather irrelevant. I do not think people will switch to video using Theora when a technically superior alternative exists that will also work in Internet Explorer (Flash). We have to make sure that video is on par technically with what Flash can do. Technical arguments are relevant here, so take some time to consider them before accusing people of having shady ulterior motives. Technical arguments are relevant, but do not control. They are neither the only nor the most important consideration. Similarly an inadequate open standard should not be proposed as the only way forward simply by virtue of its openness. Wanting an open standard does not mean that Theora should just be automatically chosen to be that open standard. It is also a logical error to assume that openness is not desired by a vendor merely because one potential open format is not approved by that vendor. dave ([EMAIL PROTECTED])
Re: [whatwg] Asynchronous database API feedback
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx = db.createTransaction();
tx.add(db.sql('create table if not exists chickadees(name text, kind text)'));
tx.add(db.sql('insert into chickadees values(?, ?)', ['moesha',
'black-capped']));
tx.add(db.sql('select * from chickadees', [], function(rs) {
console.log(rs.rows.name); }));
tx.execute(function(error) {
console.log('bird flip!');
});
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [], function(rs) {
console.log(rs.rows.count); }).execute();
What do you think?
:DG
Re: [whatwg] Asynchronous database API feedback
Can you help me understand the problem you're pointing out? The
difference between the idea outlined and the current spec is the
absence of the transaction callback, but it basically (I think) has
the equivalent net effect.
db.createTransaction is just a mutable list of statements until the
execute method is called. In fact, it could even probably be just a JS
array.
tx.execute(..) immediately returns, then asynchronously (pardon the
sketchiness):
* opens transaction
* calls optional errorCallback if fails
* proceeds to execute statements in queue
* calls optional successCallback upon success.
I don't see it as being too much different from the spec's transaction
steps. In fact, I can easily see this written as a JS wrapper around
the current spec.
:DG
On Dec 12, 2007 12:33 PM, Brady Eidson [EMAIL PROTECTED] wrote:
I think the issue you're forgetting is when opening a transaction can
fail. The transaction callback is only called when the transaction is
successfully opened and you know that it is starting out valid.
~Brady
On Dec 12, 2007, at 9:37 AM, Dimitri Glazkov wrote:
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx = db.createTransaction();
tx.add(db.sql('create table if not exists chickadees(name text, kind
text)'));
tx.add(db.sql('insert into chickadees values(?, ?)', ['moesha',
'black-capped']));
tx.add(db.sql('select * from chickadees', [], function(rs) {
console.log(rs.rows.name); }));
tx.execute(function(error) {
console.log('bird flip!');
});
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [], function(rs) {
console.log(rs.rows.count); }).execute();
What do you think?
:DG
[whatwg] A possible solution to the submarine patent issue (was: Re: So called pre-exising use by large companies)
(this might sound a bit odd, but bear with me) How do we test a patient that doesn't want to be tested?, said House. I don't think there are any easy answers here. About the best solution I can come up with is to provide browser detection of media formats. That way web developers can do a runtime test for a media format and tell the user Hey, you need to install a plugin if the format chosen by the website is not available. Since the vast majority of computers have MPEG4 support, that will likely become the resulting standard like JPGs and GIFs. With this idea (a good one) you don't even *need* to do runtime detection. The browser can just send an Accept: application/ogg, video/mpeg, mime/type and the server can decide which file to serve, and if no content type satisfies that, then the server returns the appropriate HTTP response which should make the browser look the codec up in a registry. That way, we can have a third-party organization distribute the Theora/Vorbis codecs and Ogg container format demuxers, and every big player is automatically free from the burden of responding to patent trolls, because big organizations in fear of torpedo lawsuits won't be distributing or manufacturing risky technology. If enough people push long enough and hard enough for Theora, it will become a new standard alongside these existing formats, much like PNG. Especially if a few major web browsers ship Theora support long enough to assuage fears over its unknown patent status. Using the third-party registry / distributor solution (that, I hear, has already been proposed), would let Opera and Mozilla (and WebKit distributors) ship Ogg Theora / Vorbis embedded, while serving the needs of Microsoft, Apple and Nokia simultaneously. Using a phrase from Taub, we don't subtract, we *add*. And let's not forget that all Linux distributors already distribute Ogg technology. Thanks, Jerason Banes On Dec 12, 2007 6:00 AM, Sanghyeon Seo [EMAIL PROTECTED] wrote: From what I read, it is argued, that pre-existing use by large companies is a good indication of less risk for submarine patents. It is also argued, that Theora has not much pre-exsting use by large companies, and among others, H.264 does. Is this really true? I have a hard time believing that no large companies shipped Theora decoder ever. And how large is large? I would appreciate any information on this matter. -- Seo Sanghyeon -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ You prefer the company of the opposite sex, but are well liked by your own. signature.asc Description: This is a digitally signed message part.
Re: [whatwg] Ogg content on the Web
Geoffrey Sneddon schrieb: Apart from those two, the others I can think of are those that are in excess of twenty years old (and therefore their patents have expired), such as H.260. I couldn't find anything insightful about H.260. Sure you don't mean H.120, which is a 1982 video codec I couldn't find a current implementation of? (Which would explain why Wikipedia is not using it even if it doesn't happen to hopelessly behind in basically every aspect imaginable) H.261, OTOH, is a 1990 standard and thus still a bit away from getting absolutely free. Maik
Re: [whatwg] several messages regarding Ogg in HTML5
Hi Guido, The point of a patent research is to reduce the risk. Since companies seem to be afraid there may be submarine patents and thus Theora expresses a large risk for companies to support it, the way to reduce the perceived risk is to do an independent analysis of the technology incorporated in Theora about patents that it may be infringing. This could be funded through all the interested parties together, including open source/standards organisations like Mozilla or Xiph, but must be undertaken by an independent organisation. The W3C is the right organisation IMHO. As for the mobile argument - Theora has been demonstrated to work on chips using HW acceleration, so I cannot really see a problem with that. Regards, Silvia. On Dec 12, 2007 7:35 PM, [EMAIL PROTECTED] wrote: Silvia, By definition submarine patents are patents nobody knows of, except its owners, who might just wait until a deep pocket company has shipped a considerable amount of products before requesting this company to compensate them for their IP they are using in this product. W3C has no possibility to detect or even prodect from these patents. Pls see our position paper of the W3C Video on the Web workshop. The other issue that might have gotten less attention in recent mailing list and Slashdot discussion is the availability of chipsets that support a considered codec for desktop and embedded environments. Silicon support is essential for battery-powered devices. A pure SW implementation of a codec will be slower and will drain the battery way faster than a codec that relies on HW accelleration. But lets examine the outcome of the W3C workshop. Cheers - Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Silvia Pfeiffer Sent: 12 December, 2007 08:24 To: Dave Singer Cc: WHATWG Proposals Subject: Re: [whatwg] several messages regarding Ogg in HTML5 On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote: Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a) examine the declaration, licensing, and patent expiry situation for various codecs; b) contact the licensing authorities for various codecs to determine their level of interest and flexibility, and possibly invite them to the December workshop. c) analyze the open-source codecs for their risk level, and possibly seek statements from patent owners if that is deemed prudent; What was the consensus on the what to do question? I would be quite interested to get c) undertaken and see how real the submarine patent threats are. Is that a real possibility for the W3C to do (I mean: financially speaking)? Also, if there is any potential that large patent owners could make statements about the applicability of their patents to these open specifications, the let's try it! Regards, Silvia.
Re: [whatwg] Removal of Ogg is *preposterous*
On Dec 12, 2007, at 6:38 AM, Elliotte Rusty Harold wrote: David Hyatt wrote: Fear of submarine patents is only one reason Apple is not interested in Theora. There are several other reasons. H.264 is a technically superior solution to Theora. Ignoring IP issues, there would be no reason to pick Theora over H.264. Everyone wants an open freely implementable codec, but it doesn't follow that Theora should automatically be that codec. About the only argument I've heard in favor of Theora is that it's open, but that is an argument based purely on IP and not on technical merits. Openness is a prerequisite. Technical adequacy is a prerequisite. The technically best solution is not a prerequisite. In case it isn't obvious yet, an open, adequate format is preferred over a better proprietary one. I don't think that is obvious at all, especially when the video tag's chief competition, Flash, is using the technically superior solution. Why would authors switch away from Flash if video doesn't offer any technically compelling reason to switch? If you consider mobile devices that want to browse the Web, then depending on the constraints of the device, a hardware solution may be required to view video with any kind of reasonable performance. A mandate of Theora is effectively dictating to those mobile vendors that they have to create custom hardware that can play back Theora video. Given that such devices may already need a hardware solution for existing video like H.264, it seems unreasonable for HTML5 to mandate what hardware a vendor has to develop just to browse Web video on a mobile device. Thanks. I wasn't previously convinced we needed to mandate *any* particular format, but you just convinced me. If hardware is support is required for some devices, then it does indeed sound like a good idea to mandate some minimum level of conformance. It is far better that this minimum level of conformance be an open, freely implementable standard such as Ogg/Theora than a known patent encumbered format such as H.264. Good. I also believe there should be a mandated baseline. That's why I think SHOULD is too weak, and that we should be working towards a MUST. Or put another way, imagine that GIF was an open format but PNG was IP-encumbered. Would you really want to limit the Web to displaying only GIFs just because it was the only open image format available? Please stop attacking straw men. No one has suggested that. Under those circumstances, I absolutely would support requiring all browsers to display GIFs. This would not prohibit them from also displaying PNGs if they chose to license the relevant patents. Right, but, continuing the analogy, the issue you run into is if the Web at large considers PNG to be superior and just ends up using it anyway, then specifying SHOULD use GIF is rather irrelevant. I do not think people will switch to video using Theora when a technically superior alternative exists that will also work in Internet Explorer (Flash). We have to make sure that video is on par technically with what Flash can do. Technical arguments are relevant here, so take some time to consider them before accusing people of having shady ulterior motives. Technical arguments are relevant, but do not control. They are neither the only nor the most important consideration. Similarly an inadequate open standard should not be proposed as the only way forward simply by virtue of its openness. Wanting an open standard does not mean that Theora should just be automatically chosen to be that open standard. It is also a logical error to assume that openness is not desired by a vendor merely because one potential open format is not approved by that vendor. dave ([EMAIL PROTECTED])
Re: [whatwg] Ogg content on the Web
David Gerard writes: In any case, the point remains: Theora is the only practical option for video on Wikimedia sites at present, so that's one top-10 source of video that will greatly be enabled for the end user by HTML5 having a video tag with Ogg Theora as the default (even as a SHOULD). Not quite. That's one top-10 source of video that will greatly be enabled by browsers supporting Theora. Your claim (that it would benefit from the spec saying browsers SHOULD support Theora) is only true if there are browsers which would only support Theora because of the spec saying that. Some browser creators have made it clear they woudln't support Theora, even with a SHOULD. Other browsers will Theora anyway, because they want to, regardless of whether the spec even mentions it -- and the more that Wikipedia uses it, the more that browsers are going to want to support it simply in order to be Wikipedia-compatible (regardless of whether the spec says browsers should be Wikipedia-compatible). Smylers
Re: [whatwg] Asynchronous database API feedback
On Dec 12, 2007, at 11:18 AM, Dimitri Glazkov wrote:
Can you help me understand the problem you're pointing out? The
difference between the idea outlined and the current spec is the
absence of the transaction callback, but it basically (I think) has
the equivalent net effect.
In the current spec, you know exactly when your transaction is in
flight and available, because of the callback. That's why
executeSql() is only allowed from within a transaction or statement
callback.
An app might decide to do something differently if the transaction
callback doesn't come within a certain timeout, for example.
Additionally, the current spec reflects the reality that a transaction
might not be allowed - getting the SQLTransactionErrorCallback right
away.
Additionally, it is a common pattern to execute different sql
statements based on the outcome of the previous statement or based on
other program state when the time comes to decide what statement to
execute next.
Your proposed model hides these realities to various degrees. By
allowing a queue of statements to build up then pulling the trigger,
there's no definitive point in time where the transaction actually
begins executing, and a lot of work might be wasted queueing up a long
list of statements before pulling that trigger, and other flexibility
might be lost.
db.createTransaction is just a mutable list of statements until the
execute method is called. In fact, it could even probably be just a JS
array.
Making it an array seems flawed - separate method calls is the right
way to go, I think.
tx.execute(..) immediately returns, then asynchronously (pardon the
sketchiness):
* opens transaction
* calls optional errorCallback if fails
* proceeds to execute statements in queue
* calls optional successCallback upon success.
The current spec prevents you from queueing up statements until the
transaction is guaranteed to be open already. Speaking with direct
implementation experience, I can attest that this is a Good Thing
(tm). See some of the reasons above.
I don't see it as being too much different from the spec's transaction
steps. In fact, I can easily see this written as a JS wrapper around
the current spec.
If you think your model is easier, then I agree completely that it can
be implemented as a JS wrapper around the current API. But it hides
details and options available in the current API as previously
discussed. It would be good for some developers (I'm assuming you ;)
but not for others.
One thing your model would do over the current spec is make the API
more complex. I see more fuzzy interactions between the objects and
more methods that don't make as much sense to me as the current spec.
For example...
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [],
function(rs) {
console.log(rs.rows.count); }).execute();
Huh? While I think the ability to simply execute a single statement
without worrying about callbacks and transactions is valuable, the
above syntax combined with the previously described relationship
between db.sql() and tx.execute() makes my brain explode. :)
I don't disagree that a simple way to execute a single statement is
valuable, but I was thinking something more along the lines of using
the current model as-is, and adding a method to database that has the
first statement queued up in a transaction already.
~Brady
Re: [whatwg] Ogg content on the Web
On 12 Dec 2007, at 19:30, Maik Merten wrote: Geoffrey Sneddon schrieb: Apart from those two, the others I can think of are those that are in excess of twenty years old (and therefore their patents have expired), such as H.260. I couldn't find anything insightful about H.260. Sure you don't mean H.120, which is a 1982 video codec I couldn't find a current implementation of? Yeah. I always miscall it H.260 (as it is the precursor to H.261). H.261, OTOH, is a 1990 standard and thus still a bit away from getting absolutely free. Though, by the time we reach LC, it may not be. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 17:44, David Gerard wrote: On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. Why must video just one of many unencumbered formats? Er, what are the others? Technically speaking, Theora is actually unencumbered (it just has a RF license covering the patents from On2). Dirac is in a similar situation. Apart from those two, the others I can think of are those that are in excess of twenty years old (and therefore their patents have expired), such as H.260. Dirac is not finished, H.120 has no extant codecs. I may as well call motion PNM an unencumbered video format. In any case, the point remains: Theora is the only practical option for video on Wikimedia sites at present, so that's one top-10 source of video that will greatly be enabled for the end user by HTML5 having a video tag with Ogg Theora as the default (even as a SHOULD). Claims that there are no sources of content are simply factually incorrect. - d.
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 12 Dec 2007, at 14:23, David Gerard wrote: So far we have had zero patent trolls come calling. I wonder why that is. Do you have enough money to pay a fine a similar size to what MS got last year? If you don't have enough money, they won't sue you. It isn't worth their time. Not to mention Patent Troll Sues Wikipedia would be second only to Patent Troll Eats Cute Fluffy Kittens for mediapathy. Mind you, the people who hate Wikipedia *really hate* Wikipedia, and I'm amazed none of them have even made noises in this direction, given the ridiculously broad and vague software and business method patents that exist in the US. That said, we do actually go to considerable effort to do the right thing because it's the right thing - we don't allow patent-encumbered formats because they would severely reduce the reusability of our content, and deliberately flouting assumed-valid US patents (as odious as software patents are) would be unseemly. - d.
Re: [whatwg] whatwg Digest, Vol 33, Issue 90
Dnia 12-12-2007, Śr o godzinie 08:59 +, Ian Hickson pisze: Most people don't mark up abbreviations or acronyms at all, they only mark them up at all to give the expansions generally. And for this purpose, it doesn't really matter which is which (not to mention that different people disagree on which is which -- I say ess quere ell and ewe are ell, others say sequel and earl). SQL and URL are acronyms because they are built from initial letters. Mr., Dr., Ch. and cf. are abbreviations. i.e. and etc. are... er... abbreviations? Except for these cases, I hardly see any valid disagreement. A rule of thumb is that abbreviations are usually written with a dot. Chris
Re: [whatwg] Ogg content on the Web
On 12/12/2007, Smylers [EMAIL PROTECTED] wrote: Not quite. That's one top-10 source of video that will greatly be enabled by browsers supporting Theora. Your claim (that it would benefit from the spec saying browsers SHOULD support Theora) is only true if there are browsers which would only support Theora because of the spec saying that. Technically this is true :-) But in practice, I can't tell you how happy we were when we heard Ogg Theora would be in HTML5 (even as a SHOULD). Video is important as educational material, and video support in the MediaWiki software has been a major pain in the backside. Current support is a kludgy pile of stuff that degrades somewhat gracefully through a sequence of free-software and not-quite-free-software (VLC plugin, QuickTime plugin, there's JavaScript, there's a bit of Java, there's Flash that sorta works in Gnash, etc - I'm not absolutely clear on the details and I'm sure someone will be along to correct me shortly, but they're pretty murky details ;-). A VIDEO tag that can be reasonably assumed to support Ogg Theora and Ogg Vorbis would make our lives and our readers' browsing significantly happier. Some browser creators have made it clear they woudln't support Theora, even with a SHOULD. Other browsers will Theora anyway, because they want to, regardless of whether the spec even mentions it -- and the more that Wikipedia uses it, the more that browsers are going to want to support it simply in order to be Wikipedia-compatible (regardless of whether the spec says browsers should be Wikipedia-compatible). Including, I suspect, Safari - which has a Wikipedia link in the default bookmark bar - and Nokia - what use is a phone that can't show you the video on Wikipedia that explains your point precisely when you're arguing over something in the pub? What sorta rubbishy phone is that? Tch! Shoulda got an iPhone! *cough* We're only one site that would significantly benefit from a VIDEO tag that can reasonably be assumed to do Ogg Theora, but we're a reasonably significant one I think. - d.
Re: [whatwg] A possible solution to the submarine patent issue (was: Re: So called pre-exising use by large companies)
On Dec 12, 2007, at 21:08, Manuel Amador (Rudd-O) wrote: The browser can just send an Accept: application/ogg, video/mpeg, mime/type and the server can decide which file to serve, and if no content type satisfies that, then the server returns the appropriate HTTP response which should make the browser look the codec up in a registry. HTTP content negotiation has various problems that I'm not going to elaborate on here. Instead, the HTML5 spec draft has a mechanism where the server (in the HTML5 document) advertises what it has to the browser and the browser chooses based on its knowledge of its decoder capabilities. Please see the spec: http://www.whatwg.org/specs/web-apps/current-work/#location You can find test cases here: http://hsivonen.iki.fi/test/moz/video-selection/ -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] The truth about Nokias claims
They are acting with their shareholders in mind. They have everything to gain and nothing to loose as they all have their platforms, i.e. Window, OS X, Itunes, cellular handset, that they control/use their propiety formats. It costs them to switch and they have the possibility of loosing their current dominant position. It's not a good business decision for them to endorse something they have less control over. Marc On Dec 11, 2007 5:15 PM, Manuel Amador (Rudd-O) [EMAIL PROTECTED] wrote: Thanks for your research, Shannon. Quite enlightening. Show of hands: who here believes that the anti-Ogg camp is acting selflessly, with no vested interests, and in the best interest of progress and other W3C values? El Mar 11 Dic 2007, Shannon escribió: This is an except from an MPEG-LA press release: Owners of patents or patent applications determined by MPEG LA's patent experts to be essential to the H.264/AVC standard (standard) include Columbia University, Electronics and Telecommunications Research Institute of Korea (ETRI), France Télécom, Fujitsu, IBM, Matsushita, Mitsubishi, **Microsoft**, Motorola, **Nokia**, Philips, Polycom, Robert Bosch GmbH, Samsung, Sharp, Sony, Thomson, Toshiba, and Victor Company of Japan (JVC). So lets review the three companies loudly objecting to OGG, misrepresenting its status and continuing to fuel this debate: Apple: Has heavy investment in H.264, AAC and DRM via iTunes. Known for proprietry hardware lock-in. Microsoft: Heavy investment in WMV and DRM. 'Essential patent holder' in H.264. Major shareholder in Apple. Known for proprietry browser and OS lock-in and standards disruption. Nokia: 'Essential patent holder' and heavy invester in H.264. Argued for software patents in EU. Stop believing their lies! Don't you think it's weird that Nokia is complaining about patents while simultaneous holding numerous video related ones? OGG/Vorbis/Theora are open and as safe as codecs can get. Its patent risks are practically non-existent. It has no licensing fees. It is easy to implement across all major (and most minor) platforms. It is the format of choice - unless you're Nokia, Apple or Microsoft. Finally, nobody has mentioned that the licensing terms on H.264/AVC state that in about 8 years from now ALL internet H.264 content and software becomes licensable. Sites will have to pay to use it. It is NOT FREE, just 'on hold' until adoption becomes widespread and enforcement more practical. When that happens guess who makes billions? Nokia and Microsoft. These companies have no right to be distrupting this list and modifying the standard to their whims. Their business interests are of no interest here. This is a PUBLIC standard, not a proprietry one. Put the OGG reference back in the HTML5 draft, exactly as it was, as it was originally agreed, as many have requested - AS IS APPROPRIATE! Shannon [EMAIL PROTECTED] -- Manuel Amador (Rudd-O) [EMAIL PROTECTED] Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Keep emotionally active. Cater to your favorite neurosis.
Re: [whatwg] Proposal for New Tag for UI Elements
Dnia 12-12-2007, Śr o godzinie 14:44 +0100, Thomas Broyer pisze: Only kbd inside kbd would be boxed then, so the + sign is not a problem: In this case you have to say KBD twice in simple cases, which is unacceptable because it is unexpected and it is going to be overlooked/ignored by the authors. pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd (hold kbdShift/kbd down while pressing kbdF3/kbd, then release both keys, in any order)/kbd./p Or eventually: pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd/kbd (i.e. hold kbdkbdShift/kbd/kbd down while pressing kbdkbdF3/kbd/kbd, then release both keys, in any order)./p
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 12-12-2007, Śr o godzinie 00:21 -0500, Manuel Amador (Rudd-O) pisze: Look, guys. I don't think I've explained myself well, partly because I've come on too strong. There is no evidence of malice. There's also no evidence of profiteering. There *is* evidence of immorality, if you define spreading falsehoods as immoral (see Ogg is proprietary comment). The rest of the discussion is basically a disagreement on how risky it would be to implement Ogg on browsers. Some of us don't feel it's risky, others feel it's too risky to even consider (I understand -- billions of dollars may be at stake). And both threads are pointless and irrelevant.
Re: [whatwg] Video codec requirements changed
Dnia 12-12-2007, Śr o godzinie 00:11 -0500, Manuel Amador (Rudd-O) pisze: I'd rephrase it as # Has had traction, time and exposure in the market, enough so patent threats should have arisen already. That is, as a study of a troll's lifestyle shows, indefinite.
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
Dnia 11-12-2007, Wt o godzinie 19:26 -0500, Jeff McAdams pisze: If the text is changed to move away from a free and open solution to something that is going to be encumbered, you better believe I'm going to be up in arms about it, and I will not apologize for it. This change is exactly that sort of change. And you must be... Osama's nephew, right? Oh, that makes me scared. In other words, the fudded turned out to be the fudder. I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. Why don't you go call out China on Tibet, or USA on Guantanamo? It is much more important and comparably effective.
Re: [whatwg] Video codec requirements changed
Dnia 11-12-2007, Wt o godzinie 18:53 -0500, Manuel Amador (Rudd-O) pisze: Wanna know what happened to the last troll that attacked free software? Ask Darl McBride. Everyone is under the possibility of constant attack from trolls. He was not a patent troll, he was acting for Microsoft and he got his reward for that.
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 18:21 -0500, Manuel Amador (Rudd-O) pisze: That's no reason to NOT SUGGEST Ogg Vorbis / Theora. No one here is saying that HTML5 should forbid proprietary codecs -- all we're claiming for is the judicious and well-deserved mention of two free technologies in a document that will be read by MILLIONS of people to come. And you just killed that. You're exaggerating, you are. If Web developers read the specification (or any specification, for that matter), the Web would not look like it does. But they do not; the prefer Dreamweaver, and whatever you have got. Small companies aren't targetted by patent trolls. Only big (really big) companies are. And therefore they're deserving of more protection? Sounds like a racket to me. I am sorry you perceive them this way. Be honest, don't tell me you're sorry because you are not. You're sorry when something personally sad happens to someone you know, not when there's a perfectly valid disagreement on an action you took. Clairvoyant? I don't care much for the content in my own computer, since I encode my things in free formats and using free technology, but I will care when I start playing videos on my computer and it says to me you need codec X, which unfortunately is not available for your Linux computer. If you keep the section you censored, the likelihood of that happening is much, much lower. Not really. Yes, the big players here are fearful and doubtful of the uncertain patent situation surrounding Ogg. That is in fact the entire problem. How curious that the Ogg Vorbis authors never felt that fear, uncertainty and doubt. Perhaps they didn't because they actually did their homework and researched the patent minefield before stepping on one of those mines, instead of saying it can't be done, we're too afraid? Irrelevant, dismissed. Sure. We will just have to wait till we all have 50 megabits/s at home to watch 320x240 videos or something. Maybe we can convince podcast authors to start casting in RIFF WAVE -- I hear it has awesome quality at 8000 Hz mono! Then don't. Read books, it will do you more good. Sadly there's really no such thing as an exhaustive patent search. There's also no such thing as a perfect prophylactic, yet people still use condoms because they're good enough. That does not mean you can force somebody to use them when he is afraid. It'd be fantastic if someone from Xiph pronounced himself on the matter in this forum. But it would not change anything. Tactics change over time. Anyway, it's not our duty to concern ourselves with the *intentions* of the players (though I did shine some light on the issue because it's good to know what the players want). But it is our duty to reflect over the lasting consequences of our actions. This particular action, as already noted, is temporary and it is not meant to have any. Stalling Ogg for a pie-in-the-sky nonexistent solution is not the answer. Ogg is already working in many browsers (both Vorbis and Theora). Despite continued and persistent assertions by bullies (backed on NOTHING but hot air), Ogg is still the best answer. Nobody claimed it is the answer, it is just a workaround. Let me be humorous for a moment. This whole discussion (which is actually NOT representative of the interests of the anti-Ogg bullies) could be summarized as: - Apple: the neighborhood punk is out to get us - Nokia: yeah - MS: indeed - (WHATWG): OK let's just not go out of our house Nobody said that, but You are free to stay at home until we come up with a better solution. For that, we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. BMP? MJPEG? WAV? You are being told this question it will take some time to answer this question. The whole point of the change was to make the point that we need something that will not screw you. Ogg isn't a solution, as it won't be implemented by Apple and Microsoft. Honestly, if Apple and Microsoft don't implement Ogg, it will *GUARANTEED* not screw me. If you put it in the spec, they will have to implement it or -- failing that -- there are simple JS-based fallback solutions that are perfectly degradable. So there is NO excuse. It depends on Web authors, and authors rely on what they can see. Otherwise everybody would be using Q for quotations by now. For the record: I don't see a conspiracy. All I see is big interests clearly colluding in the open to further restrict choice for the rest of us. For the record: col·lude –verb (used without object), -lud·ed, -lud·ing. 1. to act together through a secret understanding, esp. with evil or harmful intent. 2. to
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 11-12-2007, Wt o godzinie 16:37 -0500, Manuel Amador (Rudd-O) pisze: Well, instead of hoping, maybe we can draw more attention to this issue so public pressure helps us do the job. This mailing list is not the best place to draw more attention though. It seems you are wasting your time (and everybody else's). Chris
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 23:20 +0100, alex pisze: First, I would like to thank you for the feedback, and I must admit it is a rather sensitive situation, more so then I imagined at first. But because of the nature of submarine patents, I don't quite see how you can actually find a codec that fits the requirements? You can't use an encumbered codec obviously, and the rest is up for grabs by people who misuse legislation for their own benefit? So what else is there (excepting codecs that are outdated in every way that is)? That said, my vote still lies with ogg. Perhaps a unencumbered codec exists that the big vendors would be unwilling to torpedo for some reason? The reason, of course, must be different than the codec in question is clear and safe; it must be an economical one. It would be interesting to see what would happen if the European Commission offered Microsoft a deal: some of the antitrust fine for OGG support in Internet Explorer. Chris
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 11-12-2007, Wt o godzinie 13:21 -0500, Manuel Amador (Rudd-O) pisze: alternatives -- thank god for Linux). I don't want to experience it all over again, especially since I know that even today, that crapware isn't even gonna be made for Linux, and I'm going to be screwed again. Meaning Totem would be unable to play what? Totem is unable to play Macromedia Flash but Flash is not being discussed here. Chris
Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)
Dear Chris, From the Oxford English Dictionary online (accessed today): initialism: The use of initials; a significative group of initial letters. Now spec. a group of initial letters used as an abbreviation for a name or expression, each letter or part being pronounced separately (contrasted with ACRONYM). acronym: A word formed from the initial letters of other words. Hence as v. trans., to convert into an acronym (chiefly pass. and as pa. pple.). This is concordant with my understanding is that in English at least, acronyms and initialisms are abbreviations, but not vice versa. That is, the set of English acronyms is a subset of the set of English abbreviations. Whether or not this is true of Polish, it should not be asserted of English. A multilingual standard should accommodate the existing practice and terminology of the languages to which it applies; it should not attempt to re-define those practices or terminologies. (If you are not convinced, then consider this analogy: should the HTML spec have insisted that all languages marked up in HTML be written from left to right, using characters called 'a', 'b', 'c', etc?) Sorry to make the point so strongly. All best, Sam On 12/12/2007, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: You may be right but this theory seems to be very specific to the English language. For example, you silently assume that URL is an abbreviation; acronyms like ZUS or PKO are not considered to be abbreviations in Polish. The term initialism is stranger to HTML so this distinction is essential for academic linguistic papers only; Aspell does not even recognise this word. However, the distinction between an acronym and an abbreviation is clear and intuitive. Chris Dnia 12-12-2007, Śr o godzinie 22:29 +, Sam Kuper pisze: Dear Chris, Your classifications are incorrect, as is your rule of thumb. The following excerpt should clarify things: Initialism[s] originally described abbreviations formed from initials, without reference to pronunciation. ... [Some people] differentiate between the [terms 'acronym' and 'initialism'], restricting 'acronym' to pronounceable words formed from the initial letters of the constituent words, and using 'initialism' ... for abbreviations pronounced as the names of the individual letters. In the latter usage, examples of proper acronyms would be 'NATO' ... and 'radar' ..., while examples of initialisms would include 'FBI' ... and 'HTML'... There is no agreement on what to call abbreviations whose pronunciation involves the combination of letter names and words, such as 'JPEG' ... and 'MS-DOS' ... . These abbreviations are sometimes described as acronym–initialism hybrids... There is also no agreement as to what to call abbreviations that some pronounce as letters and others pronounce as a word. For example, the internet term 'URL' can be pronounced as individual letters or as a single word. (from http://en.wikipedia.org/wiki/Acronym_and_initialism) Best regards, Sam -- Forwarded message -- From: Krzysztof Żelechowski [EMAIL PROTECTED] To: Ian Hickson [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 22:20:56 +0100 Subject: Re: [whatwg] whatwg Digest, Vol 33, Issue 90 Dnia 12-12-2007, Śr o godzinie 08:59 +, Ian Hickson pisze: Most people don't mark up abbreviations or acronyms at all, they only mark them up at all to give the expansions generally. And for this purpose, it doesn't really matter which is which (not to mention that different people disagree on which is which -- I say ess quere ell and ewe are ell, others say sequel and earl). SQL and URL are acronyms because they are built from initial letters. Mr., Dr., Ch. and cf. are abbreviations. i.e. and etc. are... er... abbreviations? Except for these cases, I hardly see any valid disagreement. A rule of thumb is that abbreviations are usually written with a dot. Chris
Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)
Dnia 13-12-2007, Cz o godzinie 00:43 +, Sam Kuper pisze: Dear Chris, From the Oxford English Dictionary online (accessed today): initialism: The use of initials; a significative group of initial letters. Now spec. a group of initial letters used as an abbreviation for a name or expression, each letter or part being pronounced separately (contrasted with ACRONYM). You can use an axe as a hammer; that does not make it a hammer though. acronym: A word formed from the initial letters of other words. Hence as v. trans., to convert into an acronym (chiefly pass. and as pa. pple.). This is concordant with my understanding is that in English at least, acronyms and initialisms are abbreviations, but not vice versa. That is, the set of English acronyms is a subset of the set of English abbreviations. Whether or not this is true of Polish, it should not be asserted of English. I admit I am no expert in English. I was afraid presenting my examples in Polish would not make much sense here. A multilingual standard should accommodate the existing practice and terminology of the languages to which it applies; it should not attempt to re-define those practices or terminologies. That is just what I say: Removing ACRONYM because it is a special case for/indistinguishable from ABBR makes HTML English-centric. (If you are not convinced, then consider this analogy: should the HTML spec have insisted that all languages marked up in HTML be written from left to right, using characters called 'a', 'b', 'c', etc?) Sorry to make the point so strongly. Nothing wrong with that; strong points are easier to discuss. All best, Chris
