Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)

[Sam Kuper]

On 13/12/2007, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > ... the set of English acronyms and the set of English
> > initialisms are disjoint subsets of the set of English
> > abbreviations.
>
> I don't believe they are disjoint, though I suppose you could declare
> (by fiat, perhaps falsely) that any particular word fits in only one
> category for any individual speaker.
>
> -jJ

Dear Jim,

A little further research suggests that the OED is not consistent on
this matter.

The definitions of 'acronym' and 'initialism' seem quite clearly to
indicate disjoint sets, essentially because if there were overlap
between the two sets, it would contain only terms for which
pronunciation has not been settled and cannot be settled simply by
examining the structure of the term for sufficient vowels, etc.* Such
terms, it could reasonably be argued, are not in the English language
(yet) and therefore don't count, and so the sets are indeed disjoint.
So, were it the case that 'earl' and 'yew are el' are both valid ways
of pronouncing the abbreviation 'URL', then this would be such a term.
(However, it is not: the settled pronunciation of URL is the latter of
the two above.)

However, if the above is correct, then 'JPEG' ought to be classed as
an initialism by the OED, since it cannot be pronounced as a word
(requiring, as it does, the insertion of a vowel sound after the 'J').
Yet, the OED actually classes JPEG as an acronym.

What, then, is this second ontology of initalisms/acronyms, since it
is clearly different from the first? I suspect it either desregards
(perhaps out of ignorance) the existence of initialisms as a distinct
set of abbreviations, or else regards them as a subset of acronyms.

Which ontology to choose? Take your pick. I prefer the former, as I
consider it to be better informed and also more useful. Of course, you
may differ...

Warmest regards,

Sam

Re: [whatwg] several messages regarding Ogg in HTML5

[Kornel Lesinski]

On Thu, 13 Dec 2007 00:02:10 -, Krzysztof Żelechowski  
<[EMAIL PROTECTED]> wrote:



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.


Hopefully the specification will be used as basis for many tutorials,  
books, and tools, so this suggestion may indirectly have very wide  
influence.


--
regards, Kornel Lesiński

Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)

[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

Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)

[Sam Kuper]

I realise that one paragraph of my reply was insufficiently
unambiguous. Here is how I should have put it:

This is concordant with my understanding is that in English at least,
all acronyms and initialisms are abbreviations, but not vice versa. That
is, the set of English acronyms and the set of English initialisms are
disjoint subsets of the set of English abbreviations. Furthermore,
there is a non-empty set of English abbreviations that contains no
English initialisms nor English acronyms.


All best,

Sam


On 13/12/2007, Sam Kuper <[EMAIL PROTECTED]> wrote:
> 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/A​cronym_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)

[Sam Kuper]

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/A​cronym_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] What to say about

[fantasai]

Henri Sivonen wrote:


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  element is optional: titles of 
works (and personal names) may be communicated without any particular 
markup or may be marked up as  or  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.)


Scrap it. If someone starts a flamewar, point out that a the "name" of 
"a person" can also be considered the "title" of "a work".


~fantasai

Re: [whatwg] Removal of Ogg is *preposterous*

[Krzysztof Żelechowski]

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] Vote for OGG

[Krzysztof Żelechowski]

Dnia 11-12-2007, Wt o godzinie 19:11 +, David pisze:
> Sorry for the spam and all, but I'd just like to weigh in with my
> support for ogg, and utter dismay at how it seem the process has been
> brought out by big company's.
> 

As Ian already explained several times, you do not weigh in by
supporting anything.
Chris

Re: [whatwg] several messages regarding Ogg in HTML5

[Krzysztof Żelechowski]

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*

[Krzysztof Żelechowski]

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

[Krzysztof Żelechowski]

Dnia 11-12-2007, Wt o godzinie 17:30 -0500, Jeff McAdams pisze:
> Is H.264 a better codec technically, yeah, ok, and Nokia and Apple are
> free to support it if they wish in addition to Theora, or even to
> implement all of the HTML5 spec except for Theora support and risk being
> called out as non-conformant.

I do not think the upper management would even consider avoiding this
risk.  It is all trifles to them.  I can also imagine their claiming
conformance while they actually are not, and there is nothing the
wizards can do to stop the upper management of the customers from buying
that.

> 
> >> The old wording was a SHOULD requirement. No MUST. If the big players 
> >> don't want to take the perceived risk (their decision) they'd still be 
> >> 100% within the spec. Thus I fail to see why there was need for action.
> 
> > The problem is that if the big players don't follow the spec, even the 
> > SHOULD requirements, then the spec is basically pointless. What we want 
> > isn't that some people support Ogg, what we fundamentally want is that 
> > _everyone_ support the same codec, whatever that may be.
> 
> Then revert the text and make it a MUST.  As far as I know, there are no
> other codecs out there that are not encumbered.  This is the whole
> reason for existence of Theora, at least at the time, and I don't know
> that this has changed in the few years since it was designed.

That would make the whole HTML5 thing drift off to the ocean of
self-worship.

> 
> If you want a baseline that everyone can implement without being
> encumbered, then the answer is Theora.
> 
> > 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.

And the standard really has no means to stop them, whatever it says.  Do
you want a standard that says Microsoft is nonconformant?  It already
is, has always been, and no standard is going to change that because
they do not give a damn.

> 
> > On Tue, 11 Dec 2007, Manuel Amador (Rudd-O) wrote:
> >>> It is intended to be exactly truthful, actually. I apologise if you 
> >>> believe this to be fear mongering.
> >> Well, the intentions certainly didn't match the actions.
> 
> > I am sorry you perceive them this way.
> 
> As witnessed by the large influx of people on the list that you
> referenced (admittedly including myself) that are expressing very strong
> similar opinions, perhaps you should reconsider whether this is merely a
> perception.  I think its very clear that its not just perception.  I
> think you're being played, Ian.  Revert the text and be done with this.

As Ian already pointed out, truth values do not add up.

> 
> If you really want this to be a baseline codec that everyone can
> implement, revert the text and then change it to MUST.

Are you a Wiccan or something?

> 
> >> Fact: Vorbis is the *only* codec whose patent status has been widely 
> >> researched, nearly to exhaustion.
> 
> > Sadly there's really no such thing as an exhaustive patent search.
> 
> No, but that there was an extensive attempt made make Vorbis and Theora
> much safer than the alternatives.
> 
> >> Let me rephrase your statement to be worded in a more *honest* way.  
> >> Vorbis provides the perfect escape for proprietary audio prisons.  
> >> Apple and Nokia are having problems with consumers and authors actually 
> >> waking up and using free, non-patent-encumbered, widely available, 
> >> unrestricted, non-proprietary technology.  Since Vorbis directly 
> >> threatens their ability to sell traps, they are extorting your 
> >> compliance with threats of not supporting the HTML5 spec.
> 
> > I don't know what you base your conclusions on, but I assure you that to 
> > the best of my knowledge, that's not the current situation. I have been in 
> > this business a long time, and I've been played for a fool many times 
> > before. This particular issue does not have the tell-tale signs of players 
> > acting in bad faith. Indeed, Apple employees have probably done more to 
> > resolve this issue than anyone else so far.
> 
> Really?  And Nokia calling Ogg "proprietary" doesn't raise any red
> flags?  (merely an example)  Perhaps you should take a vacation from
> this, Ian, clearly your bovine excrement meter is broken.

It does not matter whether Nokia is wrong or right, the only relevant
question is what they are going to do.  Perceive that as Gromyko talk.

> 
> > 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 artific

Re: [whatwg] several messages regarding Ogg in HTML5

[Krzysztof Żelechowski]

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, 

Re: [whatwg] Video codec requirements changed

[Krzysztof Żelechowski]

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] HTML 5, OGG, competition, civil rights, and persons with disabilities

[Krzysztof Żelechowski]

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

[Krzysztof Żelechowski]

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] Removal of Ogg is *preposterous*

[Krzysztof Żelechowski]

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] Proposal for New Tag for UI Elements

[Krzysztof Żelechowski]

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.

> 
> To make George eat an apple, press
> Shift+F3 (hold Shift down while
> pressing F3, then release both keys, in any
> order).
> 
> Or eventually:
> To make George eat an apple, press
> Shift+F3 (i.e. hold
> Shift down while pressing
> F3, then release both keys, in any order).
> 
> 

Re: [whatwg] Removal of Ogg is *preposterous*

[Krzysztof Żelechowski]

Dnia 12-12-2007, Śr o godzinie 13:12 -0600, David Hyatt pisze:
> 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   
> tag's chief competition, Flash, is using the technically superior  
> solution.  Why would authors switch away from Flash if  doesn't  
> offer any technically compelling reason to switch?

For example, because Flash is unavailable or is available in a way that
makes it inefficient with respect to open-source engines that can be
recompiled and optimised for a particular platform.

Chris

Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)

[Krzysztof Żelechowski]

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/A​cronym_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] arrggghhh (or was it ogg)

[Michael Dale]

I don't know if that entirely true..

In Lucent Technologies, Inc. v. Gateway, Inc. for example:

"Lucent had not made any representations that its patents would be 
licensed through MPEG LA; to the contrary, Defendants such as Gateway 
were informed that they would need a license directly from Lucent. 
Moreover, the MPEG LA sublicensee agreement explicitly warns that the 
MPEG LA pool *does not necessarily include all the patents necessary to 
practice the technology and that sublicensee signs the agreement aware 
of such risks*. (Blackburn Dec. Ex. 20 §§ 4.2, 4.3.)"


I am not an "expert" who can claim anything to any certainty when it 
comes to submarine patents? ...My observation of the litigation history 
shows theora is "safer" to implement than mpeg la stuff.

metavid.ucsc.ed/blog has some more "observations" to that end ;)

michael dale
metavid.org


Jerason Banes wrote:
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

[Robert O'Callahan]

On Dec 12, 2007 9:47 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> > 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.
>

I don't think so. At any time Apple could make a business decision to assume
the patent risk without changing the way they do business. For the free
software community to accept H.264 we'd need either an appropriate
royalty-free patent license (which would be fantastic, but seems highly
improbable), or we'd have to give up on free software.

Ogg isn't a choice, unfortunately.


That sounds more immutable than it is. Apple and Nokia and others could
change their minds at any time, for example if a large enough quantity of
Theora content emerged that the value to their users balanced the perceived
risk.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)

[Sam Kuper]

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/A​cronym_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] The truth about Nokias claims

[cramhead]

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] A possible solution to the submarine patent issue (was: Re: So called "pre-exising use by large companies")

[Henri Sivonen]

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] Removal of Ogg is *preposterous*

[Jeff McAdams]

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, 

I think its extremely obvious and critically important to more and more
end-users.  Apple would do well to consider this issue in more depth.
-- 
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] whatwg Digest, Vol 33, Issue 90

[Krzysztof Żelechowski]

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

[David Gerard]

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] Ogg content on the Web

[David Gerard]

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  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 
tag that can reasonably be assumed to do Ogg Theora, but we're a
reasonably significant one I think.


- d.

Re: [whatwg] Asynchronous database API feedback

[Brady Eidson]

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

[Smylers]

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] Ogg content on the Web

[Ralph Giles]

On Wed, Dec 12, 2007 at 07:47:05PM +, David Gerard wrote:

> Dirac is not finished, H.120 has no extant codecs. I may as well call
> "motion PNM" an "unencumbered video format."

Nah. MNG has delta frame compression. Much better than motion PNM. :)

 -r

Re: [whatwg] Ogg content on the Web

[David Gerard]

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

[Geoffrey Sneddon]

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

Re: [whatwg] Ogg content on the Web

[Maik Merten]

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] Asynchronous database API feedback

[Dimitri Glazkov]

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<
>
>

Re: [whatwg] Removal of Ogg is *preposterous*

[David Hyatt]

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   
tag's chief competition, Flash, is using the technically superior  
solution.  Why would authors switch away from Flash if   
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  using Theora when a  
technically superior alternative exists that will also work in  
Internet Explorer (Flash).  We have to make sure that  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] Removal of Ogg is *preposterous*

[David Hyatt]

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   
tag's chief competition, Flash, is using the technically superior  
solution.  Why would authors switch away from Flash if  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  using Theora when a  
technically superior alternative exists that will also work in  
Internet Explorer (Flash).  We have to make sure that  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])

[whatwg] A possible solution to the submarine patent issue (was: Re: So called "pre-exising use by large companies")

[Manuel Amador (Rudd-O)]

(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] several messages regarding Ogg in HTML5

[Silvia Pfeiffer]

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] Asynchronous database API feedback

[Dimitri Glazkov]

.. 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

[liorean]

On 29/12/2006, Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> wrote:
> Why would you need a plugin for  ?

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] Asynchronous database API feedback

[Brady Eidson]

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] The truth about Nokias claims

[liorean]

> 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

[Geoffrey Sneddon]

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

Re: [whatwg] Video codec requirements changed [ISSUE-7 video-codecs]

[Dan Connolly]

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] Ogg content on the Web

[David Gerard]

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] Ogg content on the Web

[ryan]

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

[Geoffrey Sneddon]

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

Re: [whatwg] Video codec requirements changed

[Geoffrey Sneddon]

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

Re: [whatwg] Video/Audio specs

[Geoffrey Sneddon]

On 12 Dec 2007, at 00:02, Fabien Meghazi wrote:


Who is against this  ?

Audio ogg/vorbis must be supported
Audio mp3 should be supported

Video container ogg with H.264 codec & vorbis audio must be supported
Video container ogg with H.264 codec & mp3 audio should be supported


Anyone who distributes free (as in beer) software. You need to pay  
patent charges for the MPEG standards.



--
Geoffrey Sneddon

Re: [whatwg] Asynchronous database API feedback

[Krzysztof Żelechowski]

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] several messages regarding Ogg in HTML5

[Jerason Banes]

(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] arrggghhh (or was it ogg)

[Jerason Banes]

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] So called "pre-exising use by large companies"

[Jerason Banes]

Here's a rundown of the major media players and their support:

Windows Media - Requires third party plugin
Quicktime 7 - Requires Xiph.org plugin 
Real Player - Requires Helix plugin

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] Removal of Ogg is *preposterous*

[Silvia Pfeiffer]

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.

[whatwg] Ogg content on the Web

[David Gerard]

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] Asynchronous database API feedback

[Thomas Broyer]

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

Re: [whatwg] Removal of Ogg is *preposterous* , SHOULD, and other matters

[ddailey]

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

[Thomas Broyer]

2007/12/11, Krzysztof Żelechowski:
>
> The + sign does not belong to the user input, it is a shortcut the
> following explanation:
> press Shift >press F3releaseF3 >releaseShift
>
> (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:

To make George eat an apple, press
Shift+F3 (hold Shift down while
pressing F3, then release both keys, in any
order).

Or eventually:
To make George eat an apple, press
Shift+F3 (i.e. hold
Shift down while pressing
F3, then release both keys, in any order).


-- 
Thomas Broyer

Re: [whatwg] several messages regarding Ogg in HTML5

[Shannon]

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  being used with other formats. Surely this will not 
destroy the  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] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)

[bofh]

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-3laJJP0&feature=related

[whatwg] arrggghhh (or was it ogg)

[Joseph Daniel Zukiger]

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] Ogg Theora vs H.264

[Mikko Rantalainen]

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

Re: [whatwg] Removal of Ogg is *preposterous*

[Elliotte Rusty Harold]

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] several messages regarding Ogg in HTML5

[Maik Merten]

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.

[whatwg] So called "pre-exising use by large companies"

[Sanghyeon Seo]

>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 (was: Re: Joe Clark's Criticisms of the WHATWG and HTML 5)

[Henri Sivonen]

On Dec 11, 2007, at 12:53, Ian Hickson wrote:

I am still on the fence about using  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 .
 * 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  from such content. Hence,  
 should probably be kept as conforming part of the language.
 * Considering the default presentation of  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  for personal names  
without getting into flame wars.
 * Considering that during the existence of  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  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  
. Specifically, the spec should say something that'd protect  
authors who don't mark titles of works as  (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  instead  
of whatever command-i produces in Dreamweaver.)


So that leaves that spec should say that  is part of the  
language. If it helps the styling goals of the author, it's OK to mark  
up titles of works as , but it is OK not to mark up titles of  
works as . Plus some weasel words that effectively allow markup  
up names of people as  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  element is optional: titles of  
works (and personal names) may be communicated without any particular  
markup or may be marked up as  or  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]

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  
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 specifyin

Re: [whatwg] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)

[Ian Hickson]

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] more discussion regarding codecs (Was: whatwg Digest, Vol 45, Issue 16)

[Stewart Brodie]

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] several messages regarding Ogg in HTML5

[Maciej Stachowiak]

On Dec 12, 2007, at 1:30 AM, Jeff McAdams wrote:

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.


This makes it sound like you are just advocating Ogg, rather than  
advocating royalty-free as a requirement for a baseline codec. That  
doesn't seem like a principled position in favor of open source and  
open content, it just seems like Ogg fandom.


In particular:

1) Theora is a patented encumbered (with a royalty-free patent  
disclaimer), so that's not a basis to contrast it to other codecs that  
may have royalty-free patent availability.


2) I'm not aware of significant patent research having been done on  
Theora, unlike the case with Vorbis. If anyone knows otherwise, please  
cite a reference.


3) Pre-existing widespread use by large companies in practice  
mitigates submarine patent risk more than research. So actually a  
royalty-free license to a widely used codec would be better from a  
patent risk point of view.



I hope those who advocate Ogg for reasons of open source compatibility  
and freedom of content creation would agree that any royalty-free  
technically suitable codec would do. Otherwise, you are just making it  
harder to find a baseline that will work for everyone.



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.


Incidentally, and for the record, no Apple employee has demanded that  
the Ogg SHOULD-level requirement be removed. We specifically said we  
can live with it, although having it in the spec seems unhelpful.  
We're also working to find a mutually workable solution by proposing  
alternatives and negotiating with the relevant parties. To those of  
you posting angry emails, consider whether you could find a way to  
contribute to resolving the situation.



Regards,
Maciej

Re: [whatwg] several messages regarding Ogg in HTML5

[Jeff McAdams]

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 t

Re: [whatwg] several messages regarding Ogg in HTML5

[Ian Hickson]

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] lede element

[Ian Hickson]

I read all the e-mails quoted below, and my conclusion is that  or 
 is not compelling enough to warrant its own element. It's also not 
_that_ common -- a sample of a dozen or so news sites indexed by Google 
News for the keyword "first lego league" just now didn't find any articles 
with leads (though a wider search did find a couple that had summary 
paragraphs before the article itself, which could arguably be taken to be 
lead paragraphs).

I think that  is actually the right element to use here -- "a span of 
text to be stylistically offset from the normal prose without conveying 
any extra importance". I've added an example to the spec that shows how to 
do this.


On Mon, 1 Oct 2007, Devi Web Development wrote:
> 
> The lede element is an inline element useful for signifying the lede in 
> a document. It is commonly used term in journalism for the opening 
> sentence or two which introduces the article. More detailed description 
> can be found at 
> http://en.wikipedia.org/wiki/News_style#Terms_and_structure
> 
> Usage Case:
> 
> Burmese monks 'to be sent away'
> Thousands of monks detained in Burma's main city of Rangoon 
> will be sent to prisons in the far north of the country, sources have 
> told the BBC. About 4,000 monks have been rounded up in the past 
> week as the military government has tried to stamp out pro-democracy 
> protests. They are being held at a disused race course and a technical 
> college. Sources from a government-sponsored militia said they would 
> soon be moved away from Rangoon...

On Tue, 2 Oct 2007, Rachid Finge wrote:
>
> The term 'lede' is more commonly spelled as 'lead' by journalists 
> throughout the world. It seems like a sensible idea, although I'm 
> wondering why you added the P element in your example.

On Tue, 2 Oct 2007, Richard Conyard wrote:
>
> Whilst I can see the removal of the span, in your example where would it 
> differ from a strong (apart from strong being semantically recognised). 
> Is there really enough of a need here to create a new element rather 
> than using existing patterns of  or strong / em styled 
> with CSS to achieve the same result?

On Tue, 2 Oct 2007, Stijn Peeters wrote:
> 
> Anyway, I think this is a sensible idea indeed. I suppose the  
> element would be used inside a  element, surrounding the first 
> sentence or so, as a lead/lede is different from (or, as far as I know, 
> a part of) the first paragraph.

On Wed, 3 Oct 2007, Thomas Broyer wrote:
>
> That's my opinion too. An  would start with a  
> containing its title, author, publication date, followed by the  
> (inside a  for a lede, or as a block-level container for a nut graf) 
> and then the article body. The lede/nut graf could eventually be 
> included in the  instead of following it (à la Libération.fr).

On Wed, 3 Oct 2007, Matthew Paul Thomas wrote:
> 
> In that example from BBC News, the paragraph is actually four 
> paragraphs.  BBC 
> News always puts a  element around the first paragraph of a story. 
> But they also bolden the second paragraph, if it's explaining the source 
> of the story: ... 
> 
> 
> So to satisfy the use case of the BBC,  would need to be a block 
> element. I haven't found any examples where it would be an inline 
> element.
> 
> My local newspaper uses a similar pattern:  
>  (To future 
> readers: this link probably will have died in a few months.)
> 
> Same with ZDNet News, who forget the  tags entirely:  
> 
> 
> Except where BBC News boldens the second paragraph, these examples could 
> all be satisfied by CSS to select the first paragraph inside the article 
> container. I doubt any news site would deliberately make the lede a 
> paragraph other than the first one ("burying the lede") *and* want it 
> specially formatted.

On Wed, 3 Oct 2007, Thomas Broyer wrote:
>
> AFAIK, Libération (a French newspaper) uses one-sentence-long ledes,
> and puts them right between the title and author of the article. The
> lede is also used as a summary for the article on the main page.
> 
>
> It could be "somewhat transparent", used either as a container for 
> block-level elements or as the first child of a block-level element, 
> containing significant inline content.

On Tue, 2 Oct 2007, Devi Web Development wrote:
>
> The proposal was purely for the sake of semantics. A  
> styled appropiately via CSS works and looks fine. The element would 
> obviously add no functionality. However, I though that this element 
> would add more semantic richness and would be useful to news aggregators 
> in particular as an alternative to using the first sentence (Google), 
> the first paragraph (Yahoo) or the meta description(bbc).

On Tue, 2 Oct 2007, Charles Iliya Krempeaux wrote:
> 
> On the Microform

Re: [whatwg] several messages regarding Ogg in HTML5

[Jeff McAdams]

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

[whatwg] Acronyms (Was: Video proposals)

[Ian Hickson]

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  in favor of .  I'm emotionally attached to
> .  I use it a lot, and really do feel like it is semantically
> different from .  Asbjørn Ulsberg suggest replacing both with
> . [1]

If it helps you deal with the way the spec is written, you could pretend 
that  and  were both merged into one element , and 
that that element was later renamed ...


> 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  for shorter date format, but  would 
> make more sense).

We have  for that now.

(The rest of the e-mail will be handled along with other  
feedback.)

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Elements from HTML3.0 (Was: XSLT: HTML 5 --> HTML)

[Ian Hickson]

On Thu, 8 Feb 2007, David Latapie wrote:
> 
> HTML 3.0 too had some great ideas. I'm still missing
> - FN (but CSS3 has something about footnote that may fix this)

I think we should wait to see what happens with CSS3 and maybe address 
this in markup in HTML 5.1 or 6.


> - LH (caption for list! A must-have)

Could you elaborate on this? Why is  not suitable? Can you give some 
URLs of pages that are working around the lack of an  element or 
equivalent?


> - NOTE (I use for remarks)

Does  address this?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] whatwg Digest, Vol 33, Issue 90

[Ian Hickson]

On Fri, 29 Dec 2006, Benjamin Hawkes-Lewis wrote:
>
> Anne van Kesteren wrote:
> > They are defined as being different. The former represents emphasis 
> > and the latter importance.
> 
> That's a hopeless distinction (nor IMHO do the longer descriptions in 
> the draft adequately explain when to use one and when to use the other: 
> the use-cases look interchangeable to me).
> 
> OED Online (subscription-only) defines "emphasis" as: "Stress of voice 
> laid on a word or phrase to indicate that it implies something more 
> than, or different from, what it normally expresses, or simply to mark 
> its importance." Mirriam-Webster defines "emphasis" as: "force or 
> intensity of expression that gives impressiveness or importance to 
> something":
> 
> http://www.m-w.com/dictionary/emphasis
> 
> Thus "stress emphasis" is merely a presentational effect to give 
> importance to something.

I don't really agree that it's that hopeless. Could you give some examples 
where you aren't sure which element would be appropriate?


> It's bizarre that the same draft fighting so hard for an unworkable 
> distinction between  and  also abolishes a potentially 
> useful distinction between acronyms (pronounced as a single word) and 
> other abbreviations.

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").


BTW I couldn't see anything I could really fix in the spec to address your 
comments in:

   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008849.html

Let me know if you have any specific requests relating to that e-mail.

Cheers,
-- 
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

[Ian Hickson]

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:
>
>
>  
>  12.12...
>  
>

Fixed, along with some examples.

-- 
Ian Hickson

Re: [whatwg] The truth about Nokias claims

[Arve Bersvendsen]

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


I believe Microsoft sold off their Apple stock years ago.

--
Arve Bersvendsen

Developer, Opera Software ASA, http://www.opera.com/

Re: [whatwg] several messages regarding Ogg in HTML5

[Ian Hickson]

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] several messages regarding Ogg in HTML5

[guido.grassel]

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] several messages regarding Ogg in HTML5

[alex]

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. 

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

* We could convince the MPEG-LA group to provide a royalty free license 
  for one of their codecs, e.g. H.264 Baseline.


Very unlikely.

* We could wait for Ogg to be used by a large fraction of the Web 
  population, as that would provide the business reason for companies 
  like Apple to support Ogg.


Without the standard? Highly doubtful.

* We could use an codec old enough that all patents claimed to 
  be essential to its implementation have expired.


Highly useless. Bandwidth & quality are still end user concerns.

The way i see it there are 3 possibilities so far:
- use ogg, possible (but negligable) risk of submarine patents
- use extremely old technology
- use another free codec which has a 100% guarantee that there are no 
patentholders lurking
this does not exist (afaik)

At the end of the day, I think little choice remains except ogg.