Re: [whatwg] The truth about Nokias claims
They are not easy ways forward, I agree. How would _you_ recommend addressing Apple's requirements while still addressing the requirements of the rest of the community? I would recommend that Apple and Nokia follow the example set by Goomplayer (and others) by allowing users to download codecs on-demand from third-party providers (like Sourceforge). This puts the risk squarely in the users court and better yet allows Safari/Quicktime to adapt to new codecs in the future. It may be my foggy memory but last I checked Quicktime could already do this. If such a time comes that the patent risk is resolved they could bundle it then. However, most media players are bloated enough without bundling every codec so it's really a win for everybody. If this still wasn't enough then they could join a patent pact with other large vendors to provide a mutual defense / shared liability fund. If Ogg was under threat they'd probably get the FFII to help them fight it pro-bono. THESE THINGS ARE IMPOSSIBLE! THEY ARE NOT OPTIONS! As it says in my .signature -- things that are impossible just take longer. Yes that's very cute but it's poor policy. That kind of thinking leads kids to buy Sea Monkeys and jump off bridges wearing capes. When they grow up they lose their savings playing the lottery. It is not impossible to hope that the majority of vendors will grudgingly accept Ogg (in some form or another). It is impossible to expect anything to happen while some of the complainants have clear conflicts of interest and the sticking point is 'unknown patents' and the goal is 'everybody happy'. I really hope Apple will accept that 'submarine patents' are a risk of doing business, just as I still go to work each day even though I could get hit by a bus. Shannon
Re: [whatwg] The truth about Nokias claims
Krzysztof Żelechowski schrieb: Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Remember the - in DOCTYPE HTML? Feel free to be more specific. That prefix means that HTML DOCTYPE is not issued by an officially recognised standards body. If W3C were such an organisation, we would have a + there instead. And does that matter in any way in practice? The W3C is the de-facto sole maintainer of many technologies the web depends on. People love to use the term web standards in conjunction with W3C recommendations. Maik
Re: [whatwg] The political and legal status of WHATWG
Shannon wrote: Yes, requirements that CANNOT be met. Ever. Period. The current placeholder text proposes two main conditions that are expected to be met before vendors will 'move forward' and 'progress' will happen. It isn't a rule but there is certainly an implication that leaves a lot to be desired: a.) 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. b.) That is not an additional submarine patent risk for large companies. The first statement is reasonable, however I personally know of only 1 video codec (Theora) , and 2 audio codecs (Vorbis and FLAC) that meet it. The second statement, combined with the first is a logical trap (a paradox). All vendors who do not *currently* support the chosen format will incur 'an additional submarine patent risk'. Can you see the trap? The ONLY way to meet the second requirement is to *currently* meet the first. If all the whatwg members already did that then this wouldn't be a issue. Those claiming to want a better codec cannot possibly implement it and meet the second requirement. If it doesn't exist then how can it NOT be an additional patent risk? It's not a logical paradox. You're assuming that the /only/ reason why vendors would implement a free codec is because the HTML5 specification says they SHOULD. You're ignoring the possibility that before 2012, the same vendors implement a free codec anyway. They might have various reasons for doing so, for example: a) Someone might invent free codecs that outperform other codecs. b) Management might decide that adopting free codecs would be good for the web and their business, and take on the legal risk anyhow. c) They might need to implement free codecs to prevent users start switching to other vendors' offerings because they support free codecs. This, I think, is what Ian means by compelling content: not content he (or we) find interesting or significant (like Wikipedia videos), but content that drives users en masse to rival browsers (and, in Apple's and Nokia's case, rival phones). If vendors vulnerable to patent trolls did implement free codecs, then following WHATWG's recommendation would not involve additional submarine patent risks and both requirements would be met. NB I call this a possibility not a probability. -- Benjamin Hawkes-Lewis
Re: [whatwg] The truth about Nokias claims
Dnia 15-12-2007, So o godzinie 11:41 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Remember the - in DOCTYPE HTML? Feel free to be more specific. That prefix means that HTML DOCTYPE is not issued by an officially recognised standards body. If W3C were such an organisation, we would have a + there instead. And does that matter in any way in practice? More freedom for the consortium, I think, and less influence. For example, a law is more likely to refer to an ANSI standard. The W3C is the de-facto sole maintainer of many technologies the web depends on. People love to use the term web standards in conjunction with W3C recommendations. It is all right to be imprecise sometimes. Chris
Re: [whatwg] The truth about Nokias claims
Dnia 15-12-2007, So o godzinie 21:14 +1100, Shannon pisze: They are not easy ways forward, I agree. How would _you_ recommend addressing Apple's requirements while still addressing the requirements of the rest of the community? I would recommend that Apple and Nokia follow the example set by Goomplayer (and others) by allowing users to download codecs on-demand from third-party providers (like Sourceforge). If I were Apple, I would not want my product to be contaminated by rogue code and zombified. In case that happens, I would be held guilty, not the contaminator. This puts the risk squarely in the users court and better yet allows Safari/Quicktime to adapt to new codecs in the future. It may be my foggy memory but last I checked Quicktime could already do this. If such a time comes that the patent risk is resolved they could bundle it then. However, most media players are bloated enough without bundling every codec so it's really a win for everybody. If this still wasn't enough then they could join a patent pact with other large vendors to provide a mutual defense / shared liability fund. If Ogg was under threat they'd probably get the FFII to help them fight it pro-bono. Please observe that nobody asked you what you think Apple should do. Chris
Re: [whatwg] The truth about Nokias claims
Dnia 14-12-2007, Pt o godzinie 22:06 -0800, Joseph Daniel Zukiger pisze: Has someone made the precise suggestion I made? Specifically: (1) Require (MUST) a container/codec not known to be encumbered for the video tag. (2) Require an open plugin API for the browser, so that 3rd-party implementations can be dropped in, and allow the requirement of (1) to be met by a third party plugin. (3) Mention Ogg as an example of container/codecs which are not presently known to be encumbered. I guess I can see a problem with that if it turns out that someone can make ogg appear to be encumbered. So it would probably need (4) Allow the requirement of (1) to be waived, or commuted to the next best thing available under RAND terms in the event that there are no implementations not known to be encumbered. The codec required must be specified explicitly by name, otherwise the online world will go apart. The statements above do not make a good solution because they are not precise enough. PS: (5) Take this issue to the US Congress to explain how strong IP laws actually do interfere with innovation by anyone but 800 ton^H^H^H pound gorillas. Do you think we have a representative among us? Besides, I think they are smart enough to know that. It does not help much because they are encumbered themselves. Make a donation to nosoftwarepatents.org and stop bringing it up here. Chris
Re: [whatwg] The political and legal status of WHATWG
Dnia 15-12-2007, So o godzinie 14:24 +1100, Shannon pisze: Ian, thank you for your answers re: video codecs. I agree with you now that everything that needs to said has been said regarding the change itself and I think most parties have made it clear how they feel and what they hope will resolve it. It's clear the opinions of all parties cannot be reconciled. The current text has not reconciled the views, nor did the previous, nor can a future one. It doesn't take a genius to figure out that this will not end well. I am quite certain the issue at stake here cannot be solved at the technical or legal level at all. This is truly a political/financial matter. Which brings us to the hard questions at the crux of the matter: 1.) When a browser vendor acts clearly outside of the public interest in the making of a public standard should that vendors desires still be considered relevant to the specification? Yes. 2.) When an issue is divided between a vendor (or group of) and 'the public' (or part of), what relative weight can be assigned to each? Zarro. The decisions should be based on consideration, not on voting. 3.) When a vendor makes false or misleading statements to guide an outcome should there be a form of 'censure' that does not involve a public flame war? False statements and misleading statements are subject to criminal penalties and civil litigation. 4.) If the purpose of the group is to build interoperability should a vendor be 'censured' for holding interoperability to ransom without sufficient technical or legal grounds? No. The group should invent a way out. 5.) What methods exists to define a disruptive member and remove them from further consideration? I assume that there should be some policy everyone has to accept before joining the group. 6.) Should a standards body make a ruling even though some members claim they won't obey it? It depends on the ruling. 7.) Should a standards body bow to entrenched interests to keep the peace? No. Thou shalt not bow except to thy Lawd. 8.) Does the WHATWG consider itself to be a formal standards body? I am not in position to answer that question but I would be surprised if it did. 9.) Should HTML5 be put back under direct control of the w3c now that they have expressed interest in developing it? Yes. 10.) Is is appropriate for members to have discussions outside of this list, via IM, IRC or physical means not available or practical to the public? Yes. 11.) Does the group consider HTML5 to be a 'public standard' or a 'gentlemen's agreement' between vendors? Actually, a public specification. 12.) Is it even legal for the majority of commercial browsers to form any agreement that could (directly or indirectly) result in higher costs for end-users? How do you prevent a 'working group' from becoming a cartel? Yes, it is. Only a government can prevent a formation of a cartel and only a court can dismantle one. These are not questions that anybody can easily answer. Some have probably been answered in this list but not, at least to my reading of it, in the charter, the wiki or the FAQ (none appear legally binding in any case). It is possible the lack of clear answers in an obvious place may threaten the impartiality and purpose of this group, damage your public image and inflame debate. I believe the reason for much of the 'heat' over the video codec is due to all parties (including non-members) coming up with their own answers in the absence of a formal position. That and a lot of mistrust regarding members corporate priorities. It is very good that all parties try to present their answers. That is what the group is for. I've read the charter but it doesn't define many rules. The w3c has rules but my understanding is that WHATWG is not a formal part of w3c (even if some members are). Public acceptance of the standard may not, in practical terms, be as important as vendor acceptance (to vendors at least) but since the public is, in many ways, doing much of the vendors work for them it would beneficial to have a clearer statement of how these contributions are weighed. To cite a theoretical example: if some altruistic billionaire was to write the 'missing codec' that exceeded h.264 in compression, used 64k of ram, ran on a 386 using 50 lines of code and he The number of lines of code is irrelevant here. or she paid off all the trolls and indemnified vendors - what actions, if any, would WHATWG members take to ensure it was accepted by members with vested interests? That is, by themselves? There is hardly any need to answer that, it is their business, not ours. If that last theoretical question cannot be answered then what hope have we for a baseline video format? We hope that the issue will be resolved in due course. Chris
Re: [whatwg] The truth about Nokias claims
Krzysztof Żelechowski wrote: Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Remember the - in DOCTYPE HTML? Feel free to be more specific. That prefix means that HTML DOCTYPE is not issued by an officially recognised standards body. If W3C were such an organisation, we would have a + there instead. I haven't bought the SGML specification to double-check, so feel free to quote from it if it says otherwise. But from everything else I've read it simply means W3C has not registered a Public Text Owner Identifier with ISO. See also: http://msdn2.microsoft.com/en-us/library/ms535242.aspx http://www.is-thought.co.uk/book/sgml-6.htm#FPI http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/sgml-primer-doctype-declaration.html http://xml.coverpages.org/gca-pubidrls.html http://xml.coverpages.org/fpiResolverFlynn.html Any old organization can register as Public Text Owners, not just officially recognized standards body. The - has nothing to do to do with W3C being (or not being) recognized as a standards body. -- Benjamin Hawkes-Lewis
[whatwg] +/- in SGML DOCTYPE (was: Re: The truth about Nokias claims)
On 15 Dec 2007, at 12:52, Benjamin Hawkes-Lewis wrote: Krzysztof Żelechowski wrote: Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Remember the - in DOCTYPE HTML? Feel free to be more specific. That prefix means that HTML DOCTYPE is not issued by an officially recognised standards body. If W3C were such an organisation, we would have a + there instead. I haven't bought the SGML specification to double-check, so feel free to quote from it if it says otherwise. But from everything else I've read it simply means W3C has not registered a Public Text Owner Identifier with ISO. See also: http://msdn2.microsoft.com/en-us/library/ms535242.aspx http://www.is-thought.co.uk/book/sgml-6.htm#FPI http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/sgml-primer-doctype-declaration.html http://xml.coverpages.org/gca-pubidrls.html http://xml.coverpages.org/fpiResolverFlynn.html Any old organization can register as Public Text Owners, not just officially recognized standards body. The - has nothing to do to do with W3C being (or not being) recognized as a standards body. ISO 8879:1989 states that SGML public text owner identifier registration (i.e., those that start with a + instead of the unregistered -) is defined in ISO 9070, which I don't have a copy of. I can, however, quote the summary from ISO 8879:1989: These [registered owner identifiers] include standards body identifiers for national or industry standards organisations (similar to the ISO owner identifier), and unique codes that may have been assigned to organisations by other standards. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Reasons for moving Ogg to MUST status (was Re: HTML 5, OGG, competition, civil rights, and persons with disabilities)
Manuel Amador (Rudd-O) wrote: That's not unreasonable, but you have yet to give a solid technical reason for reverting to the old text, Reasons to put the Ogg tech suite back on the spec: - it's Free (who here hates beer or freedom?) This is a false dichotomy. (You characterise that if you don't want Ogg in the spec right now, you're against freedom. This is not actually the case.) - it's patent-unencumbered (this is a FACT) Appending FACT to something which is inherently uncertain does not make it a fact. - it's technically very good (Theora) or even superb (Vorbis and FLAC) Unsure what relevance FLAC has here. Theora is not as good as many other codecs. (If it was technically very good, in environments where codec choice has nothing to do with IP constraints -- e.g. illegal movie torrents -- then it would be used. It's not.) - it's widely available and readily installable If this is the case, then it makes little difference if it's a SHOULD requirement or not, since small authors can use it and have it easily installed when a user comes across content that uses it. - it's being integrated in popular Web browsers RIGHT NOW - it enables little guys to produce content at minimal cost Two fair points. This is not the year 2000. Mozilla and Opera are embedding Theora video. That's a user base large enough to force the rest of the players to get with the program. I very much doubt it. IE at least would have to support it before a majority of authors would use it seriously. Andrew Sidwell
Re: [whatwg] Reasons for moving Ogg to MUST status (was Re: HTML 5, OGG, competition, civil rights, and persons with disabilities)
On 13/12/2007, Andrew Sidwell [EMAIL PROTECTED] wrote: Manuel Amador (Rudd-O) wrote: This is not the year 2000. Mozilla and Opera are embedding Theora video. That's a user base large enough to force the rest of the players to get with the program. I very much doubt it. IE at least would have to support it before a majority of authors would use it seriously. IE can't really be a serious consideration here - if HTML standards had to wait on IE adopting them, this list might as well shut down now. - d.
Re: [whatwg] +/- in SGML DOCTYPE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Geoffrey Sneddon) wrote: ISO 8879:1989 states that SGML public text owner identifier registration (i.e., those that start with a + instead of the unregistered -) is defined in ISO 9070, which I don't have a copy of. I can, however, quote the summary from ISO 8879:1989: These [registered owner identifiers] include standards body identifiers for national or industry standards organisations (similar to the ISO owner identifier), and unique codes that may have been assigned to organisations by other standards. Annex K (“Web SGML Adaptations”) to ISO 8879 TC2: [[[ K.4.6 Internet domain names in public identifiers [80] owner identifier = ISO owner identifier | registered owner identifier | unregistered owner identifier | internet domain name owner identifier [83.1] internet domain name owner identifier = +//IDN , minimum data where the minimum data must begin with an Internet domain name. Note 35: A string like IDN domain.name or IDN domain.name/sub-domain/sub-domain is treated as an ISO/IEC 9070 registered owner prefix. Any sub-domains of a domain could also be identified using owner name components. For example, the Internet domain named someisp.net and its sub-domains in the URL http://www.someisp.net/users/mtb; could occur in an FPI as: +//IDN someisp.net::www::users::mtb or as: +//IDN www.someisp.net/users/mtb Note 36: When constructing a public text owner identifier using an Internet domain name, users may wish to consider the name's potential lifespan and the lifespans of the objects to be identified. Semicolon, exclamation point, asterisk, number sign, commercial at sign, dollar sign, underscore, and percent sign are members of the abstract character class special, which is usable in minimum data. ]]] - -- I'm [less] than thrilled by the [VM situation]; all sides of it. I [think] we need a [fork] in that area so that you guys would stop stepping on each others' toes. I'm taking no part in your merry 5-way clusterfuck -- sort that mess out between yourselves.-- Alexander Viro on lkml -BEGIN PGP SIGNATURE- Version: PGP SDK 3.9 wj8DBQFHZGfto/I+siR19ewRAg8hAJ9fxemTaYT63IylvCY/a9E0V0lKNQCbBjoJ gBp6BQ08364MODu+2H1igJk�j/ -END PGP SIGNATURE-
Re: [whatwg] Asynchronous database API feedback
On Dec 9, 2007 1:29 AM, Aaron Boodman [EMAIL PROTECTED] wrote: I like the new Database API design a lot, but I wish there was an option for synchronous DB access. I did some quick tests and I can insert 1000 rows, totaling 3KB+ of data into SQLite in less than a tenth of a second on Windows (I don't have a mac here, but I recall Windows was slower when we last tested). Reading takes a similar amount of time. It is definitely possible to construct queries that will take a long time to execute, but I feel that isn't the majority use case. Simple applications deal with a relatively small amount of data at a time, and disk latency isn't an issue for them. As an example, I use Gearpad (http://aaronboodman.com/gearpad) on a daily basis and it interacts with the database synchronously on the UI thread. The app feels very responsive to me. An asynchronous database API would just making writing that application harder with no real benefit. I think there should at least be the option of a synchronous API for the simple use cases. [snip] Thoughts? - a I suspect that this closely matches what actually happens in practice for most developers on the server side. When application developers prepare data for the view on the server, I believe it most often happens synchronously. Doesn't most database access in PHP and other popular environments happen synchronously? Regardles, for all web applications, unless the application has been carefully tuned to take advantage of HTTP streaming, the delivery of the UI is completely blocked until all db access has finished. It's unclear how this might affect developers using the offline API. Ben West
Re: [whatwg] Asynchronous database API feedback
On Dec 15, 2007 5:36 PM, Benjamin West [EMAIL PROTECTED] wrote: It's unclear how this might affect developers using the offline API. Ben West Thought I'd add that for many developers, the issues with asynchronous APIs requiring callbacks are difficult to overcome. The examples shown so far have been simple procedural examples, which mainly express a trivial stylistic difference. Many javascript libraries use object oriented methods, which require the use of closures to bind callback methods to their owning objects (in order to not lose a reference to 'this'). This turns out to be a fairly confusing concept. No pun intended. There is also a performance hit for using this binding technique, although I don't know how it would compare with the average time the UI would be blocked by synchronous retrieval. I suspect that for most typical uses on most typical runtimes, most developers would choose to risk the performance hit of synchronous access to the complexity of binding methods to their objects. I suspect this allows faster prototyping with a migration to more robust and flexible code, as well. It would be great if there was a way to measure this. Ben West
Re: [whatwg] Asynchronous database API feedback
On Dec 15, 2007, at 6:00 PM, Benjamin West wrote: I suspect that for most typical uses on most typical runtimes, most developers would choose to risk the performance hit of synchronous access to the complexity of binding methods to their objects. I suspect this allows faster prototyping with a migration to more robust and flexible code, as well. It would be great if there was a way to measure this. Experience at Apple with Dashboard widgets suggests that many developers will use the synchronous version, not be aware an asynchronous version exists, and be mystified by reports of hangs or blame the hangs on the operating system. This is currently happening with the widget.system function offered by Dashboard JavaScript as well as with the synchronous form of XMLHttpRequest. While it's hard to measure this phenomenon, we know it's happening a lot because of the hang reports that we get direct from some customers from the Apple tool called Spin Tracer and it's a regular point of confusion with developers on the Dashboard development list. Some developers have said things like, The code is running in a setTimeout (or XMLHttpRequest) callback function so there's no way using a synchronous call could affect user interface responsiveness. Unlike the hypotheticals in this thread, in most of the cases discussed on the Dashboard developer mailing list, conversion to an asynchronous model would be trivial. On the other hand, I agree that doing complex operations with an asynchronous callback model is inconvenient. Doing the same thing with threading is also difficult, but the difficulty arises in different ways. But synchronous calls without threading are simply not good enough for software that's going to be used by people other than the ones writing it. -- Darin
[whatwg] HTML5 and URI Templates
While I am certain some folks may not appreciate the departure from the
engaging and entertaining debate over video codecs, I wanted to offer a
minor feature suggestion [1] with regards to HTML5 forms and URI
Templates [2].
The gist of the idea (which I believe may have been brought up before
but I'm not certain) is to allow the use of a URI Template in place of
the form element action attribute, and to use form elements to provide
the replacement values, e.g.
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
- James
[1] http://www.snellspace.com/wp/?p=827
[2] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-02.txt
