[ANSOL-geral] E-mail e OpenOffice WAS: E-mail e Unicode

[Fernando Silva]

On 10/8/07, Bruno Rodrigues <bruno.rodrigues  litux.org> wrote:
> On Oct 8, 2007, at 22:31 , Fernando Silva wrote:
> De uma forma resumida:
> 1. XHTML2 foi uma tentativa de quebrar com o que existia e dar o salto
> não contemplando compatibilidade quer com HTML4 e XHTML1
>
> 2. HTML5 surgiu como forma de evoluir com base no HTML4
> Bzzzzz. quase! :P
>
> O XHTML foi uma forma de definir um novo standard onde ou se respeita
> cegamente o standard a 100%, ou se se cometer um erro, por mais pequeno que
> seja, leva-se uma valente sapatada. Como toma por base o XML puro, qualquer
> erro que um designer faça iria causar um erro indecifravel que o utilizador
> nunca iria perceber.

Um designer que comete erros desses, é *mau* designer. Um designer que
não verifica o seu trabalho e o deixa passar com erros é um *péssimo*
designer


> Digo "iria" porque XHTML nunca chegou a existir no
> mundo real, apenas XHTML disfarçado de HTML e entregue com content-type
> text/html. Mesmo no caso do XHTML Mobile Profile, largamente usado nos
> telemoveis, nunca foi XHTML puro.

Certissimo.

> Foi aí que o pessoal do WHATWG percebeu o cerne da questão e quebrou as
> ligações com a W3C e o XHTML2.

Errado. O objectivo foi "evitar" trabalho a refazer código com anos, e
tentar re-utilizar ao máximo o que já existia, conseguindo no entanto
evoluir.
Vais ver que o ponto de situação agora é um XHTML5 onde a semnântica é
strict, mas que usa coisas do velhinho HTML4.

> - é muito mais eficaz definir standards que documentam a realidade existente
> do que criar standards completamente novos e esperar que todo o mundo o siga
> e respeite, por muito correcto academicamente que o novo standard seja.

Sim, se "eficaz = fácil". Agora se eficaz significar outros conceitos
(como interoperabilidade) já não é assim! Sabes lá o que custa
desenvolver designs que funcionem em Firefox e IE6? Aliás, essa
questão de "não ter standards" levou à situação interessante IE6 vs
IE7!

> - qualquer standard têm de ser baseado no principio "Be strict in what you
> send, but generous in what you receive.", o tal que gerou esta discussão.
> Quem vai gerar conteudo é humano e irão sempre haver erros, portanto é da
> responsabilidade do browser/"consumer" entender o que recebe e corrigir o
> que fizer sentido.

Errado mais uma vez! Muitos dos erros de HTML que existiam (e existem)
devem-se a aplicações que erradamente tratam o HTML. O Frontpage e
Word faziam asneiras, logo o IE6 resolvia-as! Nada mais e nada menos
do que isto. Todo o problema começou por uma "revolta" e "re-invenção"
afastada do standards.

Quem gerava a maioria do HTML era o programa, logo *tinha* de estar correcto!

> - assumindo que irás receber sempre lixo, o HTML5 predispos-se a documentar
> o "lixo" mais comum num standard, de forma que toda a gente seja coerente na
> "generosidade".

Mais uma vez errado. Assumindo, essa perspectiva, passamos a ter
sistemas mágicos a gastar recursos a tratar lixo, quando desde o
inicio podiam estar limpinhas.

Se tiveres um carro a poluir demais e a gastar demasiado combustivel,
o que fazes? Mandas reparar ou trocas. Não vais dizer que as pessoas
têm de ser generosas e aceitar a tua poluição.

> Tal como disse noutro email, HTML ganhou ao XHTML,

Havia mais programas a utilizar HTML para o comum dos mortais. As
ferramentas mais recentes, todas elas, trabalham com XHTML.

> RSS ganhou ao RDF (puro),

Não tenho conhecimentos para argumentar

> e o REST tem ganho aos XMLRPC's e SOAP's. Tudo standards "real-life", cheios
> de indefinições que o "mercado" encarregou-se de corrigir, vs. standards
> academicamente correctos que ninguem tem vontade de olhar para.

Nada haver! Completamente fora de contexto. O REST (ou mais na moda
AJAX e o fantástico JSON) tem muita saída por uma razão muito simples:
é muito mais lógico enviar um objecto Javascript que *automaticamente*
é interpretado pelo motor, do que enviar noutro formato e gastar
recursos a fazer o parsing. Performance e poupança de recursos foram
as razões primordiais.

O XMLRPC é bastante usado noutro tipo de aplicações, como por exemplo
uma aplicação desktop a comunicar com um website, onde tem de seguir
uma API de comunicação estável e definida para todos.

O SOAP?! Queres mesmo discutir isto aqui? Terei todo o gosto de o
discutir numa thread adequada.

> Voltando à questão inicial, se um "consumer" receber algo que não está 100%
> correcto e for "fazível" detectar o erro e corrigir, para mim é um BUG
> quando a app não o corrige.

Quem define o que é fazível? Tu? Eu? Deus? O que para ti é fazível,
para outro pode não ser. E é aqui que entram os standards: como
mediadores para que toda a gente fale a mesma lingua. Achas que estás
certo:
1. convence todos os outros a fazer como achas ou
2. muda o standard ou
3. desenvolve uma aplicação que ganhe mais de 50% de mercado.

> No caso especifico do kmail, quando nem sequer
> há uma definição do charset, e quando é fácil entender que o conteúdo é
> utf-8 e não iso-8859-1, para mim é um BUG que devia ser corrigido. Se
> procurar bem no bugtracker do kde deve ainda haver por lá um bug meu.

Até concordo contigo que sendo simples, poderia estar feito, nesta
situação em concreto. E em todas as outras que não poderia? Mais uma
vez, haveria sempre alguém a dizer que uma "martelada" aqui e outra
"martelada" acolá faria a aplicação funcionar.

Nesta conversa toda, estás a fazer uma assumpção muitissimo errada:
assumes que o erro de um programa é erro humano (no sentido do
utilizador)! Não podias estar mais longe da verdade. O erro de um
programa é humano sim, mas de um programador, que deve saber o que
está a fazer. Senão sabe, mais vale estar quieto!

Fernando