Anuncios Rails vs. Resto do Mundo (Java, PHP,...)

O railsenvy.com produziu quatro vídeos (o quarto ainda não está publicado) análogos aos anúncios Apple vs. microsoft. Só coloco esta entrada aqui e não nos osmeusponteiros.blogspot.com pois este tema, Rails, é um dos tópicos a tratar aqui. Os meus apontadores é um local onde coloco ligações comentadas para coisas que me interessam mas não fazem parte dos temas a tratar aqui no ainda a pensar. Cuidado para não ter muitas visitas sou um chato nele, logo à cabeça, depois não digam que não avisei.

Dobras

Há cerca de 17 dias vi, e resolvi inscrever-me, num dos planetas, claro que foi o planetgeek.org uma entrada sobre o folding@home. Devo admitir que conhecia um projecto concorrente, quanto à computação em grelha, o boinc (seti), mas que vai muito para além de aplicações em medicina.

Quer o primeiro quer o segundo projecto têm mensagens importantes de dádiva e partilha.

Tive um primo que era dador de sangue quando jovem (foi lapidado aos 23/24 anos), anos mais tarde eu próprio me tornei dador de sangue, algo que não faço há já 4 anos (fui operado duas vezes com transfusões - já agora sou dos que fazem disparar os alarmes dos pórticos dos aeroportos). Como só dentro de uns meses voltarei a poder dar sangue esta foi uma forma de participar.

Hoje ao fim de 17 dias alcancei os 10.000 pontos (essencialmente obtidos com um portátil.) Aguardo que a minha mama acorde após a sesta da manha e já agora a da tarde também

As diferenças entre =, ==, equal? e eql?

Em ruby um sinal de igual (=) significa que se atribui à identificação da esquerda o que está à direita.

saudacao1 = "Viva Catarina."
saudacao2 = "Adeus."
saudacao3 = "Viva Catarina."

Se quisermos perguntar se o conteúdo de saudacao1 é igual ou não a saudação3 exprimimos tal usando a segunda expressão == (dois sinais de igual como sucede com várias outras linguagens de programação). Neste caso o valor devolvido é verdade. Se usarmos a expressão equals? aquilo que estamos a perguntar é se duas referências para objectos apontam para o mesmo objecto (não se esqueçam que em ruby tudo é um objecto), o que no caso de saudacao1 e saudacao3 é falso. Finalmente eql? responderá verdade pois compara valores.

Soluções simples

Por vezes as soluções mais simples são as mais apropriadas. Recentemente na lista de correio comp.lang.ruby surgiu algumém a perguntar se havia um modo de passar o nome equivalente de um modelo (exemplo: tenho um modelo designado por dept_alimentar e desejo passar a string "dept_alimentar" e depois converte-lo (ou molda-lo [cast]) no modelo original equivalente e assim posso usar o seu objecto no método chamado, estou a tentar fazer isto pois quero evitar passar um objecto o que se tornará muito pesado).

David Chelimsky respondeu no seu tom extra humilde (que caso não estivesse a entender a questão o que sucede com frequência) é que quando se passa o dept_alimentar ou DeptAlimentar para outro método, não há a passagem do objecto propriamente dita mas sim a de uma variável que detem uma referência para o objecto. O que é sugerido de facto torna-se mais caro tem termos de cálculo do que usar uma variável.

Joost-II

Quem deseja um convite agora pode convidar-se a si mesmo, para isso basta ir à página do joost.

Balázio seguiu o teu convite como não seu o teu nome nem o teu apelido ficas-te com um nome de utilizador deverás aborrecido.

FilipeEstou com dificuldades para me ligar ao Joost, logo que possível trato do teu caso.Filipe o seu convite seguiu. Pedro continuo sem o teu mail, sem isso nada posso fazer.

Pedro Moreira não tenho o teu e-mail não te posso convidar excepto se mo fizeres chegar. Julgo já teres percebido que não publicorecuso os e-mail que venham nos comentários desta entrada.

A Joost está quase quase a lançar-se comercialmente. Os actuais subscritores irão puder enviar convites num número não limitado, de acordo com GigaOm.

Já agora tenho convites para quem quizer. Basta deixar nos comentários nome, apelido e email (estes comentários não necessitam de ter mais nada e não serão publicados no blog). .

Nelson, Hugo e Marco os vossos convites seguiram. Quem quiser é só pedir. Fernando seguiu o seu e o do Paulo (13-05-2007).

Vitor e Tiago os vossos convites seguiram.

João segui um convite para ti e outro para o zeca. Como te tentei explicar quantas mais pessoas de um ISP usarem mais útil é para todos os seus utilizadores.

REST explicado à minha mulher (Tradução)

Ryan Tomayko escreveu um ensaio onde explica de forma clara o que é REST à sua mulher.

http://tomayko.com/articles/2004/12/12/rest-to-my-wife

A minha mulher: quem é Roy Fielding?

Eu: Um tipo. Brilhante.

A minha mulher: O que é que ele fez?

Eu: Ajudou a desenvolver os primeiros servidores de web e de seguida efectuou um número de investigações sobre o porquê do funcionamento da Web. O seu nome aparece no documento técnico que define o protocolo usado para recuperar as páginas de um servidor para o teu navegador.

A minha mulher: Como é que isso funciona?

Eu: A Web?

A minha mulher: Sim.

Eu: Bem, é espantoso. O caso é amusant é que é verdadeiramente subestimado. O protocolo de que falamos chama-se HTTP pode fazer muitas coisas verdadeiramente geniais que um bom número de pessoas ignora por uma ou outra razão.

A minha mulher: Queres dizer que o http como no início de uma linha que escrevo no navegador?

Eu: Sim. Essa primeira parte que diz ao navegador qual o protocolo a utilizar. Aquilo que escrever é um dos mais importantes desenvolvimentos na história da informática.

A minha mulher: Porquê?

Eu: Porque descreve a localização de qualquer coisa não importando aonde no mundo e a partir de que ponto no mundo é pedido. É o princípio fundador da Web. Uma maneira de o imaginar será as coordenadas GPS para o conhecimento e a informação.

A minha mulher: Para as páginas Web?

Eu: Não importa para quê. Verdadeiramente. Este tipo, Roy Fielding, fala disso muito nos seus trabalhos de investigação. A Web foi construída sobre um estilo de arquitectura designado por REST. REST fornece a definição de um recurso, que é aquilo que vemos na ponta.

A minha mulher: Uma página Web é um recurso?

Eu: De algum modo. Uma página Web é a representação de um recurso. Os recursos são justamente conceitos. Os URL essas coisas que escrever no navegador...

A minha mulher: Eu sei o que é um URL...

Eu: Bem. Eles dizem ao navegador que há um conceito nalgum local. Um navegador pode então pedir uma representação particular do conceito. De maneira específica, o navegador pede a representação página Web do conceito.

A minha mulherQuais são os outros tipos de representação disponíveis?

Eu: De facto, as representações são uma das coisas que são raramente usadas. Na maior parte dos casos, um recurso só tem uma única representação. Mas há a esperança que as representações seam utilizadas mais no futuro pois há um número de formatos importantes que estão a aparecer um pouco por todo o lado.

A minha mulher: Como por exemplo?

Eu: Bem, há o conceito que as pessoas designam por "serviços Web". Isto cobre coisas diferentes para pessoas diferentes mas o conceito elementar é que as máquinas poderiam utilizar a Web do mesmo modo que as pessoas o fazem.

A minha mulher: Ainda algo do género do robot?

Eu: Não propriamente. Não penso que as máquinas se sentem a uma mesa e naveguem na Web. Mas os computadores podem usar os mesmos protocolos para enviar mensagens uns aos outros. Fizemos isto há muito tempo mas nenhuma das técnicas que usamos hoje funciona muito bem devido à necessidade de termos que falar a todas as máquinas no mundo inteiro.

A minha mulher: Porquê?

Eu: Porque ainda não são concebidas para funcionarem deste modo. Quando Fielding e os seus colegas começaram a construir a Web, ser capaz de falar com todas as máquinas não importando onde no mundo era uma exigência primeira. A maior parte das técnicas que utlizamos no trabalho para fazer comunicar os computadores entre eles tinham essa exigência. Nós tinhamos só a necessidade de falar com um pequenos grupo de máquinas.

A minha mulher: E agora, temos necessidade de falar com todas as máquinas?

Eu: Sim e mais. Necessitamos de falar com todas as máquinas a propósito de todas as coisas contidas nas outras. Necessitamos de um meio pela qual uma máquina fala com outra a propósito de um recurso que poderá estar eventualmente disponível numa terceira máquina.

A minha mulher: O quê?

Eu: Digamos que falas com a tua irmã e ela te pede emprestada a bicicleta, mas que quem a tem é a vossa mãe. Donde dizes à tua irmã para falar directamente com a tua mãe. Isto sucede actualmente permanentemente na via actual e o mesmo sucede a todo o momento quando as máquinas começam a falar entre elas.

A minha mulher: Como é que as máquinas dizem umas às outras onde se encontram as coisas?

Eu: Através do URL, está claro. Se todas as coisas de que as máquinas tenham necessidade de falar possuirem um URL correspondente, criamos o equivalente máquina de um nome comum. Que tu, eu o resto do mundo tenhamos optado por falar dos nomes do mesmo modo é verdadeiramente importante, não?

A minha mulher: Sim.

Eu: As máquinas não têm nomes universais - é por isso que são nulos. Cada linguagem de programação, cada base de dados, ou um outro sistema têm uma forma diferente de falar de nomes. É por isso que os URL são tão importantes. Tal permite a todos os sistemas trocar com todos os outros a propósito dos seus nomes.

A minha mulher: Mas quando vejo uma página Web não penso desse modo.

Eu: Ninguém. Só Fielding e muito poucas outras pessoas. É por isso que as máquinas hoje continuam a ser nulas.

A minha mulher: e a propósito de verbos, pronomes e adjectivos?

Eu: Tem piada que fales disso, pois trata-se de outro aspecto importante do REST. Em todo o caso os verbos são outro aspecto do REST.

A minha mulher: Só estava a brincar.

Eu: É uma piada interessante, mas de facto não é uma piada. Os verbos são importantes. Existe um conceito poderoso em programação que a teoria de informática designa por polimorfismo. É uma maneira técnica de dizer que os diferentes nomes podem ver-se aplicados ao mesmo verbo.

A minha mulher: Já não brinco.

Eu: Bom... Vê a mesa do café. Quais são os nomes comuns? Chavena, Tabuleiro, Jornal, Controlo remoto. Agora, quais são as coisas que podes fazer com todas estas coisas?

A minha mulher: Já não brinco.

Eu: Posso apanha-las (get) certo. Podes apanhá-las. Podes bater-lhes, Podes queimá-los. Podes aplicar estes verbos exactamente a quaisquer objectos que se encontrem aí.

A minha mulher:Sim e?

Eu: Bem, isso é importante. Se em vez de te poder dizer apanha a chavena, apanha o jornal ou apanha o controlo remoto o que sucederia se tivessemos que usar verbos diferentes com cada um dos nomes? Não podia usar a palavra "apanhar" de modo universal, mas teria que pensar numa nova palavra para cada combinação verbo/nome.

A minha mulher: Oh! É estranho.

Eu: Sim. é. Os nossos cérebros são de algum modo suficientemente inteligentes para saberem que esses mesmos verbos podem ser aplicados a vários nomes diferentes. Alguns verbos são mais específicos que outros e só se aplicam a um conjunto pequeno de nomes. Por exemplo, não posso conduzir uma chavena ou beber um automóvel. Mas alguns verbos são praticamente universais como: apanhar (GET), colocar (PUT) e apagar (DELETE).

A minha mulher: Não podemos APAGAR uma chavena.

Eu: bem realmente. Mas podes atirá-la fora. Isso era outra piada. Certo?

A minha mulher: Sim.

Eu: Enfim, o protocolo HTTP que Fielding e amigos criaram é inteiramente consagrado à aplicação dos verbos sobre nomes comuns. Por exemplo, quando vais a uma página Web o navegador faz um HTTP GET do URL que escreves e de volta obtém uma página Web.

As páginas Web normalmente têm imagens, sim? Elas são recursos separados. A página Web só específica os URL para as imagens e o navegador efectua HTTP GETs suplementares de modo a que todos os recursos sejam obtidos e a página mostrada. Mas a coisa importante é que os nomes comuns de natureza muito diferente podem ser tratados do mesmo modo. Que o nome seja uma imagem, um texto, um vidéo, um mp3, um diaporama, seja o que fort. Posso obtê-los do mesmo modo com um URL.

A minha mulher: Parece que o GET é um verbo muito importante.

Eu: Sim. Particularmente quando usas um navegador Web porque os navigadores não fazer praticamente nada a não ser apanhar (GET) as xoisas. Não fazem grande coisa para além disso, poucos outros tipos de interacção com os recursos. É um problema pois tal incita numerosas pessoas a crer que o HTTP não serve para mais nada a não ser apanhar (GET) coisas. Mas o HTTP verdadeiramente é um protocolo geral para aplicar verbos sobre nomes comuns.

A minha mulher: Bom. Mas não percebo como é que isto altera algo. Que tipo de nomes e verbos queres?

Eu: Bem os nomes estão lá mas não no bom formato.

Por exemplo pensa o que sucede quando navegas num sítio como a fnac.pt para procurares coisas para me comprares pelo Natal. Imagina cada produto como sendo nomes. Agora, se estiverem disponíveis numa representação que a máquina possa compreender, poderias efectuar várias coisas interessantes.

A minha mulher: Porque é que uma máquina não pode compreender uma simples página Web ?

Eu: Porque as página Web foram escritas para serem compreendidas pelas pessoas. Uma máquina não se interesse pela apresentação e estilo. Praticamente, as máquinas só necessitam de dados. Idealmente cada URL teria uma versão legível por humanos e uma representação para máquinas. Quando a máquina apanha um recurso ela pedirá a versão apropriada legível pela máquina. Quando um navegador apanha o recurso para um humando pedirá a representação legível por um humano.

A minha mulher: Então as pessoas terão que reproduzir todas as suas páginas de modo legível pelas máquinas.

Eu: se tal foi útil. Vê, falá-mos disto com numerosas abstracções. Passemos a um exemplo concreto. És professora - na escola aposto que têm um sistema de computador grande ou três ou quatro sistemas, mais provável, que vos deixam gerir os estudantes: em que turmas se encontram, em que níveis estão, contactos de emergência, informação sobre bibliografia, etc. Se os sistemas forem baseados na Web, então é provável que haja um URL para cada um dos nomes aqui envolvidos: estudante, docente, turma, livro, sala, etc. De imediato, obter o URL através do navegador dá-te uma página Web. Se houvesse uma representação legível pela máquina de cada URL, então seria trivial encavalitar novas ferramentas no sistema porque toda a informação seria consumível de um modo padrão. Seria também fácil a cada um dos sistema falar uns com os outros. Ou poderia ser possível construir um sistema que abarcasse todo o país que fosse capaz de falar com cada um dos sistemas escolares individuais para coligir os resultados de um exame. As possibilidades não acabam.

Cada sistema iria obter informação de cada um dos outros usando simples HTTP GET. Se um sistema necessitar de adicionar algo a outro sistema, utilizaria um HTTP POST. Se um sistema quizer actualizar algo noutro sistema usa HTTP POST. A única coisa que falta e perceber como é que os dados devem parecer.

A minha mulher: Então é nisso que tu e toda a gente dos computadores está a trabalhar agora? Decidir como é que os dados devem parecer?

Eu: Infelizmente não. Em vez disso a grande maioria está ocupada a escrever camadas de especificações complexas para fazer isto de um modo diferente que não é nem tão útil nem tão inteligente. Os nomes não são universais e os verbos não são polimórficos. Estamos a deitar para o lixo décadas de utilização real em campo e técnica testadas e a começar tudo de novo com algo que se parece muito com outros sistemas que falharam no passado. Estamos a usar HTTP porque nos ajuda a falar na nossa rede. Estamos a trocar simplicidade com ferramentas espanpanantes.

A minha mulher: Porquê?

Eu: Não tenho a mínima ideia.

A minha mulher: Porque é que não dizes algo?

Eu: pode ser que diga.

O perfeito é inimigo do bom

Paul Buchheit escreveu há tempos que todos já sabemos que o óptimo é inimigo do bom. Ele acrescentou uma voltinha e diz que o bom pode ser uma barreira à criatividade.

Que não nos devemos preocupar em demasia com a nossa falta de talento, capacidades, tempo ou qualquer outro recurso que seja necessário para alcançar o bom (excepto claro em campos críticos como por exemplo a neurocirurgia onde podem acreditar em mim queremos que os médicos sejam óptimos e que a cirurgia decorra nas melhores condições).

Ele advoga que as pessoas comecem por criar um blogue, mesmo que mau (inane nas suas palavras), que se tirem más fotografias, se carreguem para o YouTube vídeos aborrecidos, que se toque má música e se faça arte horrível. Que não nos preocupemos com o bom mas que simplesmente gozemos com a alegria da criação.

O seu sonho é deixarmos o consumo passivo de entretenimento velho e aborrecido. E alegre criação do entretenimento do futuro!

Ele diz que pode suceder que após vencermos a fricção provocada pela qualidade (a que aspiramos) poderá suceder que seja criado algo realmente bom.

Mostra um exemplo do que quer dizer usando como exemplo o blogue do xkcd.

Recomendações TAC 2006

Isto é uma tradução inacabada, faltando por exemplo todas as referências

Recomendações e conclusões

1. Panorama: Os formatos abertos de comunicação de documentos para administrações públicas
2. Objectivo: Actualizar as Recomendações TAC de 2004
3. Progresso Efectuado: O que foi alcançado em termos de normalização
4. Progresso Efectuado: Actividades nas Administrações Públicas
5. Recomendações

1. Panorama: Os formatos abertos de comunicação de documentos para administrações públicas

   As comunicações entre o sector público e os cidadãos e negócios e outras administrações são frequentemente baseadas em documentos. Ser capaz de trocar documentos electronicamente entre parceiros de comunicação independentes é assim de extrema importância para as administrações públicas europeias. Devido ao seu papel social especial na sociedade o sector público deve evitar impor aos seus parceiros de comunicações o uso de produtos específicos, permitindo assim a esses parceiros a liberdade de escolha.

   As administrações públicas também têm a obrigação de manter arquivos para uso futuro, o acesso, à informação contida nos documentos, deve ser assegurado durante longos períodos de tempo.

   Assim, há um entendimento comum entre as administrações públicas na Europa de que a troca e armazenamento de documentos electrónicos deve depender de formatos abertos de documentos. Tais formatos devem ser definidos num processo aberto a todas as partes interessadas e deve estar disponível para todos os actores interessados e competentes para o implementarem sem restrições. Usar tais formatos oferece às administrações públicas, negócios e cidadãos uma gama alargada de produtos capazes de ler, escrever e manipular documentos enquanto se estimula a competição e inovação na área de tratamento de documentos.

   Preferencialmente, estes formatos abertos de troca e armazenamento de documentos devem ser sujeitos a normalização formal via procedimentos de normalização internacionais.

2. Objectivo: Actualizar as Recomendações TAC de 2004

   O programa IDABC é um programa da Comunidade Europeia cujo objectivo é identificar, auxiliar e promover o desenvolvimento e estabelecimento de serviços de eGov pã-europeus e redes que suportem os Estados Membros e a Comunidade na implementação, nas respectivas áreas de competência, de orientações e actividades da Comunidade, alcançando vantagens substanciais para as administrações públicas, negócios e cidadãos. O programa IDABC é o sucessor dos programas IDA e IDA II.

   Na sua reunião de 25 de Maio de 2004, o comité de gestão do IDA II, composto por representantes dos Estados Membros e aconselhando a Comissão sobre a implementação do programa, apoiou um conjunto de “Conclusões e Recomendações sobre Formatos Abertos de Documentos”, adiante referidos como “Recomendações TAC”.

   As Recomendações TAC aconselham o sector público a evitar impor produtos específicos aos seus parceiros de comunicação e recomenda o uso de formatos abertos de troca de documentos. Para documentos que possam ser revistos os formatos baseados em XML foram recomendados visto permitirem separação de conteúdo, estrutura, semântica e apresentação e visto poderem ser tratados por uma gama alargada de aplicações.

   As Recomendações TAC pediram à indústria que providenciassem aplicações baseadas em formatos abertos de troca de documentos que permitissem que os documentos electrónicos fossem trocados sem restrições entre autoridades e entre autoridades, cidadãos e negócios. Elas deram as boas vindas ao trabalho da OASIS sobre a normalização de formatos de documento Open Office e convidaram a indústria a juntar-se à iniciativa. As Recomendações TAC também apoiaram a submissão do OASIS Open Document Format emergente a uma organização de normalização oficial tal como a ISO. Além disso a TAC pediu à Microsoft para publicar e providenciar um acesso não discriminatório a futuras versões das especificações dos seus documentos Office e para pensar na submissão dessas especificações a um corpo internacional de normalização à sua escolha.

   Finalmente, as recomendações encorajaram o sector público a providenciar a sua informação em vários formatos. Onde por escolha ou circunstâncias só um único formato de documento alterável pudesse ser usada, este deveria ser um formato sobre o qual houvesse consenso na indústria, como demonstrado pela adopção do formato como norma.

3. Progresso Efectuado: O que foi alcançado em termos de normalização

   Recentes desenvolvimentos estão a encorajar a indústria a levar a cabo grandes esforços para alcançar os requisitos instituídos nas Recomendações TAC (e instituídas por outras organizações do sector público).

   1. Em Maio de 2005 a OASIS adoptou a especificação de documento aberto baseada em XML. A OASIS ofereceu esta especificação para normalização internacional via procedimento “fast track” da ISO em Novembro de 2005. Em 30 de Novembro de 2006 foi publicado o ISO/IEC 26300 “Open Document Format for Office Applications”. Um número crescente de produtos que suporta a norma têm vindo a ficar disponíveis.
   2. A Microsoft adoptou um formato XML “puro” para ser usado no conjunto Office 12 e submeteu a especificação OpenXML ao ECMA em Dezembro de 2005. O trabalho do grupo técnico terminou e a Assembleia Geral Internacional da ECMA aprovou o resultado do seu trabalho. A ECMA irá oferecer a especificação para normalização internacional via procedimento “fast track” da ISO. Esta normalização oferece aos concorrentes da Microsoft a possibilidade de incluírem suporte para o formato OpenXML nos seus produtos.
   3. Tantas as especificações ODF (OASIS) como as OpenXML (ECMA) estão livremente disponíveis na web e os principais contribuintes de ambas as especificações (SUN e Microsoft) asseguraram que as especificações podem ser implementadas pelas partes interessadas, incluindo programadores de open-source sem obrigações e ou custos adicionais.
   4. Tanto as especificações, de formatos de documentos das ODF como das OpenXML, são baseadas em XML, prometendo maiores oportunidades para explorar a informação contida nos documentos via ferramentas que não os tradicionais conjuntos de aplicações de escritório. Exemplos de exploração incluem a indexação de colecções de documentos, extracção de metadados dos documentos, motores de busca, extracção de informação específica para reutilização, etc…
   5. Várias equipas, incluindo uma da Microsoft anunciaram que estão a desenvolver extras open-source para o conjunto Microsoft Office facilitando a interoperabilidade entre os formatos OpenXML e ODF.
   6. Outro desenvolvimento é a adoptçãi pelo ISO/TC171-SC2 (Aplicações de gestão documental – Temas relativos a aplicações) do ISO 19005: “Gestão documental – Formato de ficheiro para documento electrónico para conservação de longo prazo parte 1, Uso de PDF 1.4 (PDF/A1)”. O PDF/A é um formato de documento não alterável que pode ser usado para documentos que não necessitem de processamento ou alteração adicionais. Embora haja muitos produtos capazes de mostrarem produtos PDF/A, só há uns poucos capazes de gerar documentos no formato PDF/A.

4. Progresso efectuado: Actividades nas Administrações Públicas

   1. Os formatos dos documentos continuam a ser importantes na agenda de orientações do sector público. Seguindo a publicação das Recomendações TAC, os directores gerais responsáveis pela administração pública da EU afirmaram nas suas recomendações de Novembro de 2004 que “Os Directores Gerais em particular dão as boas vindas à iniciativa da Comissão relativamente ao formato aberto de documento e concordam em estimular o uso do formato aberto de documento nos estados membros, uma vez tendo ele sido mais desenvolvido.”
   2. Um relatório de 2005 da Unidade Conjunta de Inspecção das Nações Unidas propôs como princípio que “Todos os Estados Membros e outros parceiros devem ter o direito de acesso público à informação tornado disponível em formato electrónico por organizações e que ninguém deva ser obrigado a adquirir um software determinado de modo a exercer tal direito.”
   3. Vários Estados Membros embeberam o uso de normas de formatos abertos para troca de documentos nas suas estratégias nacionais de tecnologias de informação ou infraestruturas de interoperabilidade.
   4. Algumas organizações deram mais um passo, reagindo ao processo de finalização da normalização da OASIS ao obrigarem ao uso do formato OASISODF. O Concelho de Ministros Belga aprovou um memorando em Junho de 2006 indicando que a partir de Setembro de 2008 todas as trocas documentais entre serviços públicos federais belgas se teria que usar uma norma de formato aberto. ODF – preferencialmente ISO 26300—é até agora a única proposta de norma aceite. O governo da região da Estremadura anunciou a migração de todos os equipamentos de secretária na sua administração para a norma ODF em Agosto de 2006. Na Dinamarca, o parlamento adoptou uma resolução em 2 de Junho de 2006 para uso de normas abertas na qual o “Parlamento pede ao governo para assegurar o uso de tecnologia de informação, incluindo software, no seio das autoridades públicas, baseada em normas abertas com início em 1 Janeiro de 2008 ou quando a tecnologia for adequada”. Um relatório com a interpretação detalhada da resolução do parlamento foi publicada em Agosto de 2006.
   5. A atenção mundial mais alargada foi atraída pela decisão (em Setembro de 2005) da Comunidade de Massachusetts (USA) para tornar o uso da OASIS ODF e PDF obrigatória na sua administração pública.
   6. A existência de normas internacionais irá claramente facilitar a aquisição de produtos que usem formatos abertos de troca e armazenamento de documentos. Alguns Estados Membros já anunciaram as suas intenções de implementar a norma ISO 26300 quando esta se tornar disponível.

5. Problemas a resolver

   Mesmo tendo em conta estes desenvolvimentos favoráveis a situação mantêm-se preocupante do ponto de vista das administrações públicas Europeias.

   Os peritos dos Estados Membros identificaram os problemas de compatibilidade esperáveis entre produtos baseados na ISO 26300 (ODF) e as aplicações comerciais que dominam os escritórios das administrações hoje como a principal barreira ao uso de formatos abertos de troca e armazenamento de documentos. A chegada potencial de uma segunda norma internacional para documentos que sejam alteráveis conduz a mais complexidade e custo acrescido. Embora filtros, tradutores e extras possam teoricamente permitir a interoperabilidade, a experiência mostra que transformações múltiplas de formatos podem conduzir a problemas em especial onde não haja uma completa correspondência entre características de cada uma das diferentes normas.

6. Recomendações

   Tendo em conta a presente situação as administrações públicas são convidadas a:

   1. Maximizar o uso de formatos abertos, normalizados internacionalmente, de troca e armazenamento de documentos nas suas comunicações internas e externas.
   2. Usar só formatos que possam ser tratados por uma variedade de produtos, evitando deste modo o uso de produtos específicos aos seus correspondentes. Quando o uso de formatos proprietários for absolutamente inevitável, formatos abertos normalizados internacionalmente devem ser providenciados como alternativa aos formatos proprietários.
   3. Adaptar, onde apropriado, directrizes e regulamentos nacionais, tendo em conta a chegada de normas internacionais nesta área;
   4. Ter em conta a definição de requisitos mínimos em relação a funcionalidades dos formatos abertos de troca de documentos com vista a alcançar a compatibilidade de aplicações;
   5. Criar directrizes para uso de formatos de documentos alteráveis e não alteráveis (com possibilidade de serem ou não revistos) de troca e armazenamento para diferentes finalidades.

   A indústria, consórcios industriais e corpos de normalização internacionais são convidados a:

   1. Trabalhar em conjunto no sentido de criarem uma só norma internacional aceite por todos para respectivamente documentos abertos alteráveis ou não-alteráveis.
   2. Desenvolver aplicações que possam tratar todas as normas internacionais relevantes deixando ao critério dos seus clientes o formato a ser usado “por omissão”;
   3. Evitar invalidar a finalidade dos formatos abertos de troca e armazenamento de documentos ao oferecerem extensões às normas internacionais relevantes como formatos por omissão.
   4. Propor testes de conformidade e desenvolver ferramentas adequadas à salvaguarda da interoperabilidade entre aplicações;
   5. Continuar a melhorar as normas existentes, também tendo em conta as necessidades adicionais tais como a assinatura electrónica de documentos.

Boas práticas - Ligações externas

Uma excelente fonte de informação sobre o uso de UTF-8 e rails pode encontrar-se em Segurar Entradas em UTF-8 em Rails.

No eigenclass encontra-se um artigo sobre tabelas fracas de chaves, versão corrigida pois havia da parte do autor um falha nos pressupostos quanto ao (momento do) funcionamento do almeida (gargabe colector) e dos finalizadores.

Teste com frequência, verifique os seus pressupostos, codifique com cuidado, leia-a os originais! (cópia descarada do eigenclass)

O Futuro da Web - Comparativo

A Digital Web Magazine desta semana apresenta uma comparação entre o HTML5 e o XHTML5 e o XHTML2 e o futuro da rede feita por David Andersson. A principal vantagem do XML de para quando seja detectado um erro na web, na sua opinião e na minha por uma visão pragmática da rede é também o seu calcanhar de Aquiles. Ele lembra que xhtml servido como text/html na prática significa ser interpretado por um navegador como uma sopa de marcação.

O segundo artigo desta semana é uma crítica do livro de Jeremy Keith "Bulletproof Ajax".

A List Apart 235

No número 235 do A List Apart Martin Kliehm fala de Aplicações Web 2.0 Acessíveis com WAI-ARIA.

Para quem não saiba ele explica muito bem as implicações das WAI-ARIA.

As nossas aplicações podem sofrer de problemas de acessibilidade devido às limitações de marcação existentes. Martin ajuda a percebermos as especificações WAI para Aplicações de Internet Ricas e Acessíveis (ARIA) para melhorar a usabilidade.

Wilson Miner apresenta um artigo para o tipógrafo que há em nós.

Código de Conduta a Resposta Burocrática

Hoje de manhã coloquei um comentário sobre o código de conduta inspirado por Tim O'Reilly. Aquilo que penso dele é que se trata de um documento sem qualquer utilidade, feito por quem tem demasiado tempo disponível, um burocrata na minha linguagem.

Recentemente Jeremy Shoemaker (n. t. sapateiro) foi indiciado sobre comentários deixados no seu blogue.

A responsabilidade acerca de um comentário deve ser imputada à primeira pessoa que se possa identificar com a afirmação em causa. Devo acrescentar que o nome indicado aquando do comentário é fácil de falsificar, o endereço de IP registado no momento do gravação do comentário idem, o endereço de correio electrónico idem, pelo que de facto os blogues não têm algo que nos permita assegurar a identidade de quem lá coloca um comentário, pelo que em último caso, a responsabilidade do conteúdo do blogue é do autor do mesmo independentemente da autoria do comentário.

Por esta razão retiro qualquer comentário que considere ofensivo ou completamente fora do tópico ou da entrada ou do próprio blogue.

Há ainda uma outra razão para retirar comentários quando tal me é solicitado pelo autor do comentário. Foi o que fiz em relação a um comentário importante que retirei a pedido do autor dos comentários de um artigo meu sobre semântica que inexplicavelmente continua a ser um dos mais lidos. Omito intencionalmente uma ligação para o artigo pois fico envergonhado sempre que vejo as estatísticas (embora estas fiquem muito bem colocadas na escala da mentira) de acesso (um dos três artigos mais lidos deste blogue).

Já agora, para terminar, ao meu comentário acima houve uma pessoa de quem gosto do blogue que me dizia que a minha observação era demasiado (para ser simpático comigo) simplista. Pois é, os valores têm mesmo que ser algo simples senão uma pessoa não consegue viver com eles, e talvez seja verdade eu ter exagerado na simplicidade.

RFC1 Faz aninhos - 38

Hoje faz aninhos o primeiro RFC 38. Este RFC este na origem da ARPANET que veio a transformar-se na Internet que hoje conhecemos.

Cábulas

• Cábula de XML[pdf]
• XSLT e XPath[pdf]
• Expressões Regulares

Cache no Google Code

O que é que acham desta técnica, colocar em cache no google os ficheiros estáticos que todos temos nos nossos sítios: obrigado Dean Edwards

DRM free

A Apple e a EMI chegaram a acordo para venda de músicas sem DRM (software anti-pirataria). As músicas livres do DRM são mais caras que com DRM.

Agora com um custo de um CD (LP) com 12 músicas o custo de um CD digital será da ordem dos 15,6 Euros e o custo de um CD com caixinha, livrinho, capinha será da ordem dos 15 Euros. Assim a EMI tem um enriquecimento sem justificação.

The Art of Agile Development

O livro em pré-publicação do Jim Shore e Shane Varden The Art of Agile Development é interessante porque reflete a filosofia por detrás do desenvolvimento Agile. Capítulo a capítulo vai sendo apresentado e comentado. Em alguns capítulos tem autores especializados como por exemplo Elisabeth Hendrickson que trata de Testes Exploratórios. A leitura dos comentários é indispensável, neste caso. Os comentários ao livro propriamente dito podem ser encontrados em: tech.groups.yahoo.com/group/art-of-agile/.

Uma pequena experiência

Por vezes é necessário experimentar para perceber o que determinada coisa pode fazer por exemplo numa das listas de correio da ruby aparecia a seguinte questão, o que é que quereria dizer algo como isto: puts gets gets (já agora na versão actual deve receber uma mensagem de aviso no caso de estas estarem activadas). Bom a melhor forma de saber o que isto quer dizer é fazer uma pequena experiência:

irb(main):001:0> puts(interior=gets(exterior=gets))
PARA
O Texto interior e este
PARA
O Texto interior e este
PARA
=> nil
irb(main):002:0> p interior
"O Texto interior e este\nPARA\n"
=> nil
irb(main):003:0> p exterior
"PARA\n"
=> nil
irb(main):004:0>

Introdução ao Governo Electrónico - Simpósio Europeu do W3C

Quem queira obter recursos deste simpósio pode ouvir e descarregar as apresentações que se encontram no programa do simpósio.

Primeira Sessão

Isto é uma tradução parcelar de: http://www.w3.org/2007/eGov/symposium-spain-report.

Peter Brown, O eGovernment perdeu-se?

• Muito do que passa por eGovernment segue o mesmo padrão: é só uma administração "baseada no papel" que usa ICT e artefactos digitais, usando aproximações velhas e familiares baseadas nos conceitos de administração pública dos séculos 19 e 20. eGovernment por outro lado deve ser mais do que isso, é um processo de profunda transformação que toca todos os aspectos de entrega do serviço e deve procurar tirar vantagens que a tecnologia oferece hoje, em vez de simplesmente mimetizar as oportunidades necessariamente limitadas do mundo baseado no papel.
• eGovernment não é tecnologia é providenciar serviços aos cidadãos
• Alguns governos estão orgulhosos dos seus projectos de cartões electrónicos de identificação, onde é mais evidente pensar em identificação electrónica: porque é que falamos sobre isto? Precisamente por que se trata de um artefacto do mundo real.
• Foram construídos demasiados portais. Os cidadãos encontram demasiados pontos de contacto com o governo/estado o que os confunde. Seria melhor integrar e oferecer um só ponto de entrada onde possível.
• Um problema específico na União Europeia (EU) é que a administração pública é exclusivamente nacional e competência de cada estado membro, e independentemente da necessidade de um número crescente de serviços trans-fronteiriços, a EU só pode oferecer directrizes e actividades de apoio. Não tem mandato para impôr nada.
• Os estados membros tendem a concentrar-se na resolução de problemas de modo local em vez de cooperarem com outros para os resolver numa escala maior.
• A cooperação deve ser principalmente conduzida ao nível organizacional/político, não tanto necessário ao nível da infraestrutura onde a federação é o caminho a seguir.
• Gestão do conhecimento: 50% dos funcionários públicos nos EUA (75% destes são gestores de séniores) irão reformar-se dentro de menos de 7 anos. As administrações têm necessidade de capturar o seu know-how antes de eles sairem.
• "Falsos picos" de Web Semântica. HTML->XML->RDF->OWL->RIF... onde é que isto irá parar? Perigo de desenvolver demasiados (e complicados) standards pode levar a que os governos tenham receio de os usar.
• É necessário manter a comunidade não tecnológica no barco. A interoperabilidade não é um fim em si mesma, é um meio para alcançar fins específicos de entrega de um determinado serviço ou necessidade.

Para uma vista mais profunda dos temas da palestra do Peter ver a sua própria entrada em: http://www.xmlbystealth.net/blog/2007/02/w3c-european-symposium-onegovernmet.html.

Daniel Dardailler

Os slides desta apresentação podem ser encontrados em: Daniel Dardailler - eGov - Gijon.

Nas suas observações finais como conclusão disse: Quem produz políticas tem que compreender os princípios e a arquitectura fundamental da Web

• Capacitadores chave: quem faz as políticas tem que compreender os princípios e fundamentos da arquitectura da Web
  • Os perítos do eGov devem envolver-se na direcção das especificações que necessitam dentro do W3C
• Elevado Impacto: O eGov deve considerar as tecnologias W3C como uma caixa de ferramentas incluindo soluções para privacidade, acessibilidade, qualidade, segurança e tratamento semântico de dados
  • O eGov deve suportar: i18n, multimodo, preparado para o móvel e acessível a todos
  • Os governos devem ajudar a definir standards Open IST e verem com cuidado a Política de Patentes do W3C

Miguel Márquez

Painel com os anteriores oradores e Klaus Birkenbihl (W3C) que o moderou e Juan Miguel Márquez (Director Geral para a Modernização da Administração do MAP). Este fez uma introdução:

• Recomendação e apoio para a substituição de procedimentos em papel por procedimentos na Internet.
  • Exemplo: o requisito de dar uma fotocópia do bilhete de identidade para cada processo administrativo. O Ministério efectuou um estudo e descobriu que em mais de 90% dos casos era desnecessário, assim deixaram de o exigir desde o início de 2007.
• O projecto do Bilhete de Identidade Electrónico (eID) um sucesso: + de 340 serviços em só 6 meses.
• Normalização: fazê-lo "no laboratório" sem ter em conta os cenários do mundo real não funciona de todo. Deve ser feito em paralelo com a implementação de soluções para cenários específicos.
• Começar localmente nem sempre é mau. A infraestrutura eID foi primeiro implementada numa dada região (Andaluzia) e depois submetida ao ministério onde teve bom acolhimento e sendo assim foi usada. As outras regiões estão agora interessadas no seu uso também.
• Por vezes enfrenta-se o mesmo problema EU ao nível nacional: os governos nacionais podem recomendar às regiões mas dificilmente podem impor.
• Interoperabilidade: ainda um problema, demasiadas propostas e teorias, pouco usadas na prática. Provavelmente um bom fundamento como critério, mas são necessárias soluções mais práticas.

Discussão da Sessão

Da discussão que se seguiu notaram-se um certo número de pontos de convergência entre os oradores:

• A forma de desenvolver serviços eGov deve ser completamente diferente da forma de desenvolver serviços baseados no papel. É necessária uma profunda transformação que toca todos os aspectos de entrega do serviço e envolve as administrações, os cidadãos e a indústria.
• As necessidades dos governos não são sempre preenchidas pelos serviços desenvolvidos pelos fornecedores de IT. A indústria deve ser mais aberta e trabalhar em conjunto com os governos para melhorar a definição de tais necessidades de modo a que os governos possam entregar melhores serviços aos cidadãos.
• Embora os projectos de eID estejam aí, há muito a fazer em termos de identidade, privacidade, confiança, por exemplo na forma de ligar os dados de eID a um único cidadão. O roubo de identidade foi e é ainda uma preocupação, por exemplo se alguém roubar o eID de outrem. Há discussões sobre biométrica e como ela pode ajudar a resolver esse problema no futuro. Peter deu um prazo de menos de 10 anos aos eID a favor da biométrica.
• Interoperabilidade ainda não está cá. É verdade que as coisas têm melhorado, que alguns governos estão a usar SOA, e que há actualmente algum trabalho mas que isso não é só um assunto técnico e que há necessidade de muitas mais soluções práticas e específicas de modo a suceder a todos os níveis.
• O uso de standards abertos é obrigatório. É actualmente difícil usar só standards abertos visto ser necessário um período de transição, mas os governos devem abraça-los gradualmente.
• O W3C tem que ver como certas tecnologias são desenvolvidas, isto é, Acessibilidade Web. Orientadas pelos utilizadores, internacionalmente aplicáveis, completamente abertas. O W3C deve pensar em ajudar e orientar a comunidade eGov de modo a alcançar estes objectivos, principalmente pensando em Melhores Práticas e tentando imaginar com a ajuda da comunidade se faltam alguns blocos construtivos que sejam necessários fazer. Os governos e a indústria devem trabalhar com o W3C para o tornarem possível.

Sessão 2 -- Governo e Cidadãos

Steven Pemberton

Steven Pemberton (W3C) abriu a sessão com a palestra Tecnologias do W3C para dessiminação de informação e interacção. Começou por fazer uma revisão das alterações no campo da interacção, desde os primórdios do HTML. Como é que o HTML progrediu, como chegou o CSS e como a batalha para a separação de conteúdo e apresentação está praticamente ganha (não viu ainda as páginas recentemente produzidas em Portugual). Deu alguns exemplos de como as CSS tornam possível a separação e de como é que já não há debate sobre a sua utilidade.

Depois explicou como é que tudo tem evoluído nos últimas anos para o XHTML2 e as XForms e quais as principais razões que as tornam mais poderosas: melhor estrutura, adicionar separação de lógica (para além da anterior separação de apresentação e conteúdo), semântica melhor e mais consistente, melhor distribuição para dispositivos diferentes, mais acessível, muito menos código. Enfatizou o poder e as vantagens de linguagens declarativas (como as mencionadas) sobre as linguagens de programação da web tradicionais tais como o JavaScript, ASP, JSP e PHP. As declarativas são mais curtas e mais fáceis de escrever, mais difíceis para se introduzirem erros, os programas são mais ligeiros, mais fáceis de testar e depurar.

Terminou dando alguns exemplos de uso real em sectores verticais, mencionando o eGov como um dos sectores onde o uso destas tecnologias pode ser muito útil como por exemplo o uso que o Planning Inspectorate do Reino Unido está a fazer delas.

Adam Bailin (Central Office of Information (COI), Governo dos RU) falou sobre Política, standards e legislação no eGov, revendo os esforços do governo do Reino Unido. Reviu a e-GIF (Infraestrutura de Interoperacionalidade do e-gov) que foi construída para alcançar interoperacionalidade entre organismos públicos. O seu uso de standards do W3C (HTML, XML, Schemas, XSLT) e de outros como o CEN, ISO e Dublin Core. Um registo central de standards, esquemas, etc é mantido pelo COI e os organismos públicos que desejam interoperacionalidade têm que os usar. Deu dois exemplos de projectos que usam o e-GIF: Government Connect que liga organismos públicos locais e central e o Government Gateway para cobrança de imposto em linha.

O governo do Reino Unido ainda enfrenta um número de desafios, os mais representativos são: os Serviços Conjuntos é normalmente difícil aos cidadãos encontrarem um ponto de entrada único para conduzirem o processo; Adam deu o exemplo de que o "Cidadão tem necessidade de contactar o estado 44 vezes após a morte de um familiar", Partilha de Dados, o governo do Reino Unido explora opções para proteger a privacidade dos cidadãos de acordo com o Data Protection Act, e o Serviço de Transformação cujos serviços devem ser orientados por requisitos de negócio e não pelos processos antigos (como tinha sido apontado por Peter Brown na Primeira Sessão).

Depois falou de eAcessibilidade. O governo do Reino Unido efectuou dois importantes estudos, um em todo o país envolvendo 1000 sítios dos sectores público e privado (2004) e outro durante a presidência da EU (2005) onde mais de 400 websites do sector público dos 25 membros da EU foram avaliados. Em relação ao último mais de 70% dos sítios Web não estavam conformes o Level A das WCAG e nenhum sítio estava conforme o Level AA das mesmas, mesmo nos países em que tal é regulamentar. Usam uma mistura de teste automático e avaliação por utilizadores e descobriram que as WCAG 1.0 cobriam só 50% do que necessitavam de verificar. Mencionou o Bristish Standard PAS 78 como o requisito legal no Reino Unido. Adam recomendou um guia (desenvolvido pelo COI) para boas práticas quando se manda fazer sítios acessíveis que funcionam de acordo com as directrizes WAI e que também define uma política de acessibilidade e a importância estratégica da eInclusão, o uso da tecnologia para evitar a exclusão social.

A terminar reviu as Directrizes para os sítios Web do governo do Reino Unido. O COI mantem o domínio .gov.uk que tem mais de 4000 sítios registados. Os cidadãos ficam confusos sobre o número de sítios web e o ponto de contacto único. O COI irá fechar 500 dos sítios nos próximos meses numa estratégia de redirigir os cidadãos para um único portal chamado DirectGov, o governo do Reino Unido irá criar campanhas individuais para alcançar uma consolidação de brand neste portal. Os desafios no futuro próximo são melhorar a acessibilidade da Web para um mínimo do Level AA e como influenciar a política ministerial do lado da tecnologia.

Eric Velleman

Eric Velleman (Fundação Bartimeus Accessibility, Holanda) falou sobre a Experiência do Cidadão com o EGov [PDF], focando os problemas de acessibilidade Web que os cidadãos enfrentam. Observou que nesta sociedade que cada vez é mais tecnológica tem também que se tornar mais social e mais universal para os cidadãos. Referiu-se a vários estudos na Holanda e na EU e mencionou alguns números a ter em conta:

• 48%, na EU, das casas têm acesso à Internet e que 23% em banda larga,
• 91% da empresas têm acesso à Internet e que 63% em banda larga,
• Que o acesso à Internet a partir de casa vai dos 16% na Lituânea aos 78% na Holanda
• que o principal meio de comunicação com o estado é ainda face-a-face (80%) e que a Internet ocupa menos de 20%.

Reviu ainda os resultados de um workshop tido pela agência governamental na Holanda em Novembro de 2006 entitulado "O que é que querem os cidadãos?" com o objectivo de identificar problemas à volta do eGov e melhorar os eServiços para os cidadãos, perguntando-lhes directamente. Analisando as respostas, descobriram que os cidadãos não sabiam exactamente o que queriam, mas que esperavam respostas claras e simples aos seus problemas. Os participantes concordaram que a informação e os serviços devem ser eficientes, eficazes e acessíveis a todos. A confiança, transparência e responsabilidade também se revelaram como temas importantes. Mencionou um exemplo de um sítio pedir informação de cartão de crédito ao cidadão quando o cidadão estava só a requerer a emissão de um novo passaporte, e esse sítio não estava debaixo da alçada do governo mas era contratado a uma terceira parte; os cidadão estão preocupados com a utilização do serviço devido a isso. Assim os governos devem rever as suas orientações políticas e tornar claro aos cidadãos porque é que perguntam dada informação de modo a que os cidadãos saibam o que esperar quando fornecem dada informação num dado sítio.

Mencionou como a Acessibilidade Web melhora o acesso à informação para todos e como é necessário melhorá-la. Bartimeus tem uma marca de qualidade para premiar sítios web que estão/são conformes as directrizes nacionais sobre o assunto, que são principalmente baseadas nas WCAG. Bartimeus testa 130 sítios web governamentais todos os anos e poucos obtém este selo de qualidade. O que é pior, detectam os mesmos erros nos mesmo sítios todos os anos embora todos os sítios novos do governo central tenham que estar conformes as directrizes nacionais (baseadas no WCAG) desde 1 de Setembro de 2006. Há uma falta de conhecimento nos governos sobre soluções, falta de harmonização entre agências e países. Eric citou dois projectos nos quais Bartimeus esteve envolvida como exemplo de melhoria: Bentoweb está a criar módulos para testar pontos de verificação WCAG adicionais e WabCluster está a produzir uma interpretação harmonizada das directrizes (Unified Web Evaluation Methodology).

Painel

Juntaram-se aos oradores Francisco García Vieira (Red.es, Agência para o Desenvolvimento da Sociedade de Informação de Espanha) para moderar o painel e José Manuel Alonso (W3C/CTIC).

Os pontos principais da discussão foram:

• A acessibilidade é importante mas deve fazer parte de uma maior grupo de requisitos para melhorar a experiência do cidadão, falta uma ligação à usabilidade. Por vezes esquecido o conteúdo é importante.
• WCAG 1.0 é bom, mas devem estar mais focados em casos práticos. WCAG 2.0 irá melhorar isto. O teste por utilizadores é importante.
• Melhores Práticas e Metodologias são vitais, mais do que standards. Os standards devem vir depois. Os governos necessitam de ajuda para escreverem os requisitos específicos nos contractos. O problema é que podem colocar algo como "esta aplicação deve estar conforme o Level AA das WCAG" e vários fornecedores não sabem sequer o que é que isso significa, alguns que o sabem, dizem que esses requisitos não estão claramente definos e que alguns não podem ser testados. É necessária mais educação e mais divulgação em ambos os lados.
• Mais e mais dispositivos disponíveis ao público e governos para oferecer serviços de eGov, telemóveis, IPTV, TDT... e a acessibilidade é imperativa para todos eles. Isto é apercebido pelos governos como uma barreira e não como uma vantagem.

Sessão 3 -- Governos e Indústria

Yves Lafon (W3C) começou a sessão a falar sobre Web Services: Blocos de Construção e Prospectiva, onde reviu a pilha de Web Services no W3C. Falou daquilo que é mais habitual ser usado e dos standards mais conhecidos na área, tais como WSDL e SOAP, como evoluíram nas suas novas versões (actualmente em desenvolvimento), e também sobre um número de novos standards tais como XOP, MTOM, WS-Policy e Choreography. Terminou falando de modos de adicionar semântica aos Web Services: Semantic Web Services, o que irá permitir que ligar a serviços assegurando que falam a mesma linguagem com o mesmo significado, isto é, unindo dados de diferentes origens ou obter os 2 serviços que de uma lista de 50 candidatos façam exactamente o que o utilizador deseja.

Serge Novaretti (Comissão Europeia) introduziu a European Interoperability Framework (EIF) que foi concebido pelo IDABC, o programa de interoperabilidade da Comissão. A Comissão Europeia não tem mandato legal por si para se tornar activa em IT; os temas de administração ou eGov são um domínio dos Estados Membros, mas a Comissão está a solicitar explicitamente aos Estados Membros que tenham representantes no seu comité de gestão. O IDABC promove e auxilia o eGov e a interoperabilidade com um orçamento global de 148.7 M EUR para cinco anos (2005-2009). Todos os seus contractos são feitos através de concurso e o seu programa de trabalho foi aprovado pelos Estados Membros e pela Comissão. O IDABC trabalha com estados membros e instituições para o estabelecimento de serviços verdadeiramente pan-europeus para cidadãos e para os agentes económicos e tem um certo número de actividades, isto é, o portal "A Sua Europa", um ponto de acesso único para os cidadãos se informarem sobre informação transfronteiriça e acesso a eServiços.

O EIF, “European Interoperability Framework for Pan-European eGovernment Services”, Versão 1.0 (editado em 2004) tornou-se um dos mais conhecidos e influentes documentos do IDABC. A maior parte do documento foi amplamente bem aceite. Várias experiências com significado com infraestruturas nacionais têm ocorrido desde a criação do documento. Os principais objectivos do EIF são auxiliar a estratégia da União Europeia para sumplementar a interoperacionalidade nacional e auxiliar alcançar interoperacionalidade. Os seus princípios subjacentes são:

• Acessibilidade e Multilinguismo
• Segurança/Privacidade
• Subsidiaridade
• Uso de standards abertos
• Aceder às vantagens do Open Source Software
• Uso de soluções multilaterais

Há algum Criticísmo/Suporte/Debate sobre afirmações sobre abertura (standards abertos e software live) e a diferenciação entre níveis de interoperabilidade. O EIF está a evoluir para a versão 2 que irá ser muito mais prática; há um estudo preparatório e irá subsequentemente ocorrer uma profunda revisão. O IDABC pensa publicar a Versão 2 no princípio de 2008.

Serge mencionou ainda brevemente dois novos projectos que estão a incubar para suportarem EIF: o desenvolvimento de uma XML Clearinghouse (câmara de compensação) e uma análise e uso de Open Document Exchange Formats. A terminar concluiu dizendo que "pensar sobre interoperabilidade é mudar de modo de pensamento."

América Álvarez González (Director-Geral IT, Governo das Astúrias, Espanha) foi para o palco para falar sobre o caso real da região das Astúrias e a sua Estratégia de EGov Aplicada (em Castelhano). Explicou como é que a região tinha progredido da sua antiga infraestrutura de IT para uma nova de modo a oferecer a melhor experiência de eGov possível aos cidadãos, construindo uma infraestrutura comum e interoperável, baseada em standards abertod que se liga internamente a todos os pontos da administração. Um desafio é ser conforme os standards, não por causa dos próprios standards mas devido ao número de pessoas envolvidos nos procedimentos: nas Astúrias um grupo de 80 pessoas de IT tem por função cuidar dos procedimentos técnicos e educar os 33 000 funcionários públicos habituados aos antigos mecanismos o que não é uma tarefa fácil.

Ela referiu várias vezes que além da tecnologia os governos têm que ter sempre em atenção as necessidades dos utilizadores e oferecerem o melhor eServiço para tal desidrato. Recomendou começar com eServiços com alto impacto, fazendo com que funcionem bem, porque assim se demonstra o potencial da eAdministração e ajuda a progredir de modo mais fácil. Para o alcançar são necessárias uma profunda mudança dos procedimentos organizacionais e da administração interna. Ela avisou ainda de que mesmo tendo alcançado este objectivo o esforço pode ser debalde se os cidadão ignorarem que o eServiço existe (é necessário publicitá-lo) ou se os cidadãos não souberem como o usar (é necessário instruí-los).

A interoperabilidade é obrigatória e uma necessidade a todos os níveis para ela: organizacional, semântico e técnico; deve ser alcançada usando standards abertos e serviços web e cooperando com diferentes níveis de administração: local, regional, nacional e europeia. A não esquecer: privacidade e segurança constroiem confiança de modo a que os cidadãos usem os eServiços.

Miguel Ángel Amutio (Ministério da Admninistração Pública (MAP), Espanha, e membro do comité de programa do IDABC) juntou-se aos oradores para um painel moderado por Alberto Mijares (CTIC). Miguel Ángel introduziu algum do trabalho do MAP, isto é, o desenvolvimento de infraestrutura de interoperabilidade nacional, no seguimento das directrizes do EIF. A interoperabilidade facilita a interacção de diferentes visões na Europa a todos os níveis, mas não é fácil de alcançar. Um número de níveis interdependentes necessitam de ser interoperáveis, desde a infraestrutura até à semântica.

Acessibilidade e uso de standards abertos (isto é como definidos pelo W3C e a sua orientação sobre patentes) muito importante; objectivo: acessibilidade à informação multicanal, integral e segura. Desafios: não há uma só referência para seleccionar de entre os multiplos standards abertos, difícil para os governos dicidirem. Além disso os governos não sabem se os standards escolhidos continuaram a ser desenvolvidos e mantidos ou se podem expirar no futuro; não está ao alcance do seu controlo visto serem desenvolvidos noutro local. Possível cooperação entre o W3C e os governos.

Após a introdução de Miguel Ángel o painel iniciou as discussões e respondeu a perguntas da audiência, de realçar:

• Web Services são uma excelente ferramenta para ajudar a que sistemas independentes possar interagir, infelizmente os produtos que os implementam nem sempre funcionam como se espera e os governos têm que investir mais dinheiros de modo a ajustá-los às suas necessidades.
• A interoperabilidade ao nível semântico é mais fácil alcançar se os dados semânticos forem expostos. É necessária cooperação entre Estados Membros para modelar estruturas comuns de dados; A Comissão Europeia pode ajudar.
• Uma infraestrutura sólida baseada em standards e serviços abertos é chave.
• A EU enfrenta um problema de multilinguismo único: mais de 20 idiomas falados e a informação tem que ser oferecida em todos eles ao nível da EU. Eis um outro desafio para alcançar interoperabilidade e fazê-lo é mais difícil acordar sobre semântica.
• O uso de Open Source Software é e deve ser encorajado pelos governos, mas tal não é suficiente. Os governos devem eles mesmo envolver-se nas iniciativas de software aberto e standards abertos e estabelecer os requisitos aí e não posteriormente. Suporte da EC; Estabelecimento de um Observatório de OSS Observatory, desenvolvimento de projectos piloto e desenvolvimento de uma licença do tipo do GPL para o seu software.
• O Procurement é outra fonte de interesse e a EU e os Estados Membros estão a passar dos seus procedimentos tradicionais, isto é aberturas de concursos, para eServiços que irão permitir, principalmente à indústria, executá-los completamente em linha no futuro próximo.

Sessão 4 - Adquirir, Arquivar e Recuperar Conhecimento: A Web Semântica

Ivan Herman (W3C) começou a sessão a falar sobre as promessas da Web Semântica, e onde introduziu as tecnologias de Web Semântica como uma aproximação para a resolução de problemas. Começou com uma tarefa que os utilizadores da web têm que usar com frequência: a pesquisa. Assim tentos responder à questão: "Quem é Viviane Redding?" (nota: é a comissária europeia para os Media e a Sociedade da Informação). Começou por mostrar como é que os utilizadores fazem a pesquisa e o trabalho manual que têm com uma grande quantidade de informação e navegar através de várias páginas até chegarem a algo realmente útil. Muitas dessas páginas são geradas por inquérito de base de dados, mas as base de dados por detrás dessas páginas não são integradas. Se alguns dos dados estiverem disponíveis para que as máquinas possas proceder a processamento adicional os dados podem ser possivelmente ser combinados e unidos numa escala global.

Mostrou um exemplo desde o início: como é que funcionaria a pesquisa da informação sobre um livro e mais informação a partir desse ponto. Referiu-se ao problema de encontrar uns pedaços de informação aqui outros ali, vindos de conjuntos de dados diferentes, todos possivelmente de diferentes origens na web, eventualmente todos com diferentes formatos. Enfatisou a importância das URI para endereçar esses pedaços de dados de modo unívoco e a importância das tecnologias de Web Semântica que permitem a esses pedaços de dados, mostrando toda a informação (combinada) de um modo consistente. Podem ser executadas várias operações sobre um novo conjunto de dados, tais como inquéritos sobre o conjunto como um todo, ou encontrar informação com um só passo. Algumas das tecnologias que foram concebidas e que são usadas para esse tipo de aplicações incluem RDF, OWL e SPARQL. Disse ainda que estas aplicações podem tornar-se mais poderosas, por exemplo usando terminologias comuns que a comunidade tenha produzido ou regras comuns, não tendo dado detalhes.

Depois referiu-se a dois temas que se pode pensar sobre a Web Semântica: é demasiado complicada e que se encontra só ao nível da investigação. Na sua opinião a primeira surge porque a indústria provavelmente necessita de mais educação e difusão sobre este novo tema e exemplos mais simples (como o usado por ele) e a segunda e em relação à segunda e última há várias pequenas empresas a usarem tecnoligia de Web Semântica, algumas criadas à volta desta tecnologia e algumas grandes que a começaram a usar, mas muitas das aplicações mais potentes da Web Semântica são usadas com dados internos. Ivan disse que se a Web Semântica vier a ter sucesso os dados devem ser expostos de modo a permitirem os inquéritos tal como ele explicou. Mostrou vários exemplos desta tecnologia em diferentes áreas: bioinformática, integração de dados, portais e mesmo para exprimir direitos autorais de conteúdo digital na Web. Juntou algumas estatísticas, mais de um milhão de utilizadores a usar CC usando RDF (de forma transparente mesmo sem o saberem).

Vassilios Peristeras e Maciej Zaremba (Universidade Nacional da Irlanda, DERI Galway) apresentaram uma infraestrutura e o projecto para alcançar serviços web pan-europeus usando tecnologias de web semântica na sua perleção WSMO-PA:Towards a generic Public Administration Service Model.

Vassilios enfatisou a importância dos serviços e a construção do Modelo de Referência de Serviço de Administração Pública. Mencionou que é muito complicado devido à necessidade de muitos concensos difíceis de alcançar. O modelod e negócio deve ser descrito de forma completamente independente da IT; deve mesmo funcionar sem nenhuma IT. Mostrou um modelo genérico que desenvolveram nos últimos 4 anos sob o projecto designado por SemanticGov, e depois passou a um exemplo específico: o modelo do serviço da licença de condução. Mencionou várias vantagens desta aproximação, como a ponte criada entre as pessoas da equipa "técnica" e da equipa "administrativa". Várias iniciativas nesta linham tais como a do OASIS, the Open Group, W3C, construíndo tecnologias semânticas orientadas pelos serviços que podem descrever a meta-camada de um lado da abstraindo-a da IT) e os blocos construtivos para o desenvolvimento da IT futuro do outro. Alguns exemplos de Administração Pública são os EGov Metadata Standards do Reino Unido e a US Federal Enterprise Architecture. A terminar disse que esta aproximação pode ser usada como infraestrutura para Serviços Web Semânticos.

Maciej partir daqui para explicar como o WSMO, um Modelo de Serviço Semântico (liderado pelo DERI), desenvolve o tipo de Modelo de Serviço para a Administração Pública detalhado por Vassilios antes, num WSMO-PA, um modelo Semântico e Formal para Serviços de eGov. WSMO-PA parte de WSMO e WSMO parte de várias tecnologias de Web Semântica.

Antonio Campos e Luis Polo (Fundación CTIC, Spain) apresentaram Ferramentas Semânticas para o e-Cidadão [pdf]. Antonio introduziu alguns conceitos de eGov e objectivos que o eGov deve alcançar. Na sua opinião, na interacção com outros governos, a indústria ou os cidadãos, os governos devem encontrar os meios mais poderosos e eficazes para comunicarem, assegurando a qualidade dos serviços públicos, melhorar a experiência dos cidadãos e melhorar a transparência e rastreabilidade nos serviços. A Web Semântica e as tecnologias de gestão de informação facilitam a interoperabilidade e interacção com e entre os cidadãos, negócios e administrações públicas dos sistemas de eGov. Disse ainda que um desafio importante para os serviços de eGov a melhorar é criar uma identidade Web única, pesquisável e confiável. Na Web Semântica os recursos têm que ser identificados de modo a falarmos deles, para os endereçarmos, tal identificação já existe no mundo real (e.g., bilhetes de ID, matrículas de automóveis, Cartões da Segurança Social) e que alguns projectos estão a experimentar o mesmo usando tecnologias da Web Semântica e metadados, tais como o «Common Procurement Vocabulary (CPV)», para normalizar referências usadas por autoridades nas suas contratações e entidades que descrevem o objecto dos contratos de aquisição; uma versão em cada uma dos idiomas oficiais na EU (20 Idiomas) está em desenvolvimento, já com 8200 conceitos (código). Acredita que estas iniciativas podem conduzir no final a soluções de eGov mais poderosas e fáceis de manter e também mais fáceis de criar. A terminar mencionou alguns projectos relativos a eGov em que o CTIC está envolvido e passou a apresentação para o Luis para o demonstrar.

Luis introduziu um projecto designado por BOPA. BOPA é o Boletim Oficial do Governo das Astúrias, uma coleção de documentos administrativos e legais editado semanalmente pelo governo regional. O boletim usa muito jargão legal difícil de ser compreendido pelos cidadãos e pela indústria. O projecto BOPA tem uma aproximação semântica baseada em ontologias e tem um motor de busca semântico para cidadãos especialmente orientado para três domínios: emprego, concursos públicos e financiamento público.

Os cidadãos ignoram o jargão administrativo e legal empregue nos boletins e falta-lhes conhecimento pericial requeiro para efectuarem inquéritos com sucesso. Assim o motor de busca permite aos cidadãos o uso de palavras comuns que conhecem e o sistema selecciona as palavras correctas (no jargão usado) para efectuar a busca. As ontologias orientam os utilizadores para os resultados. Luis fez uma demonstração da ferramenta com sucesso. Visto os boletins estarem em castelhano a ferramenta trabalha em castelhano, por agora.

Mauro Nunez (W3C) moderou um painel em seguida, onde os oradores da sessão se juntaram a María Jesús Fernández (Zaragoza, Espanha). María Jesús explicou como a Câmara observa as tecnologias da Web Semântica e construiu algumas aplicações com elas, tais como o projecto eTurismo que irá permitir aos visitantes de Zaragoza planearem os seus trajectos baseados no tempo que queiram gastar de acordo com aquilo que lhes interessa (se preferem ouvir um concerto, ver uma peça teatral, um monomento ou todos eles). Além disso disse que as actuais soluções sintáticas de busca actuais estão bem instaladas, funcionam no momento da instalação e funcionam bem e eficientemente; espera ver as soluções da web semântica melhorarem nos próximos anos.

Visto isto ter sido o último painel do Simpósio, a discussão entre os participantes e a audiência focou-se na web semântica mas houve alguns temas repescados de sessões anteriores:

• Os governos não devem inventar a roda milhares de vezes, nem mesmo devido a diferenças de idiomas. A Web Semântica tem meios para que os problemas sejam resolvidos de uma só vez. Uma das formas para o fazer é criar ontologias multilinguísticas.
• Para construir soluções bem sucedidas, ambas as camadas política/indústria e a técnica devem que ser envolvidas. O W3C pode ajudar com a última, mas a primeira está fora do seu âmbito. Uma aproximação que podia funcionar era baixo para cima: começar pequeno, resolver algum problema específico, engajar terceiros e deixar que os outros "experimentem" a solução e vejam se é útil, então tratar de os engajar, também.
• A aproximação Web Semântica é poderosa, mas tem vários desafios actualmente: se planeada correctamente não é nem barata nem fácil e há uma grande falta de conhecimento pericial tanto nos governos como na indústria.
• Partilhar é o caminho a seguir. A solução para um (isto é, o projecto BOPA) pode ser a solução para muitos. Partilhar conhecimento e tecnologia é importante. Os dados devem ser expostos.

A audiência perguntos várias vezes o que é que o W3C planeia fazer em relação ao espaço eGov. Os membros do W3C voltaram a repetir várias vezes que o Simpósio tinha sido organizado para ouvir opiniões e necessidades das partes interessadas e tentarem encontrar probelmas comuns a serem resolvidos de uma vez, mas que o W3C não o podia fazer sozinho, que as partes interessadas tinham necessariamente que participar.

Nota: E com isto fica concluída a cobertura do simpósio, falta ainda colocar as hiperligações. Agradecia ainda que me fizessem chegar quaisquer inexactidões que haja ou comentários

O Futuro do HTML

Este artigo foi apresentado originalmente por Lachlan Hunt, (tratando-se pois de uma tradução/adaptação) na reunião do Web Standards Group em Sydney em 25 de Janeiro de 2007

Pode aceder ao original, aos diapositivos de apresentação (é necessário o PowerPoint ou outra aplicação que possa ler o formato PPT) e à gravação em áudio (Ogg Vorbis) todos em língua inglesa

Este apresentação encontra-se em domínio público. Se desejar pode converter o áudio e os diapositivos para um formato diferente, faça o favor.

Evolução do HTML

No princípio dos anos 90, Tim Berners-Lee concebeu o HTML, mas não havia especificação formal escrito do HTML 1.0 e embora houvesse similaridades sintáticas com, não era baseado formalmente no SGML.

O trabalho continuou nos anos seguintes e em 1995 a [especificação] HTML 2.0 foi publicada como RFC 1866 que definia formalmente o HTML [a linguagem] como uma aplicação do SGML. Contudo os navegadores não se preocupavam ainda em implementar analisadores de SGML e, mesmo nesse período inicial, começaram a aparecer várias extensões proprietárias.

Por volta de 1996 a guerra dos navegadores estava ao rubro. Havia extensões proprietárias a voar em todas as direcções e uma abundância de páginas com erros dependentes de erros nos navegadores para poderem funcionar. Isto eventualmente veio a ser conhecido como "Sopa de Marcadores". Num esforço para normalizar este lixo, o W3C publicou a HTML 3.2 em 1997 e a 4.0 no ano seguinte que acabou por desaconselhar muitas das capacidades de apresentação que tinham acabado por penetrar.

Por essa altura parecia que a vida do HTML estaria a acabar e começou o trabalho sobre o XHTML. Após a publicação do HTML 4.01 no final de 1999 para resolver alguns pequenos problemas, o trabalho no HTML como aplicação do SGML terminou e o Grupo de Trabalho do HTML tem vindo desde aí a recomendar o XHTML.

Parecia ser um passo para se separarem eles mesmos dos grandes erros do passado, o Grupo de Trabalho do HTML começou a trabalhar nas especificações do XHTML 2.0 em 2002. Contudo, não foi concebido com retrocompatibilidade na mente, foi concebido como um novo arranque com uma nova linguagem de marcação, embora muitos considerem isso a principal barreira para que o XHTML possa levantar voo.

WHATWG

Ao longo dos anos a Apple, Mozilla e Opera têm vindo a ficar cada vez mais preocupados com a direcção que o W3C tem vindo a imprimir ao XHTML e aparentemente com o desrespeito pelas necessidades dos autores do mundo real. Assim, em 2004, dirigido por Ian Hickson, esta organização estabeleceu como sua missão ir de encontro às necessidades tanto dos utilizadores como das pessoas que fazem desenvolvimento e assim nasceu o Web Hypertext Application Technology Working Group.

Objectivos do WHATWG

Os objectivos do WHATWG incluem documentar comportamento dos navegadores actualmente existentes, normalizar extensões proprietárias suportadas de forma genéria e úteis e desenvolver novas capacidades práticas que vão ao encontro dos pedidos tanto de utilizadores como pessoas que desenvolvem enquanto se assegura a retrocompatibilidade e se definem técnicas de tratamento de erros robustas.

As Especificações

Ao longo dos últimos dois anos, têm vindo a planear e trabalhar em 3 especificações separadas: Web Applications 1.0, Web Forms 2.0 e Web Controls 1.0. Em conjunto estas três especificações são conhecidas colectivamente como HTML 5.

Web Applications 1.0

A especificação Web Apps 1.0 redefine a síntaxe e os requisitos de análise do HTML de forma a ir de encontro ao modo como os actuais navegadores tratam a sopa de marcadores, introduzindo novas estruturas e semântica de documento e APIs de DOM, muitas das quais são especialmente concebidas para construção de aplicações.

Web Forms 2.0

A finalidade das Web Forms 2.0 é expandir os formulários da HTML 4 com novos controlos, um modelo de repetição, validação do lado do cliente melhorada e uma nova API de DOM para trabalhar com formulários e controlos.

Web Controls 1.0

Por último, a especificação Web Controls 1.0 ter por finalidade melhorar o CSS e o DOM para construção de controlos e widgets. Contudo, até ao presente, pouco tem sido feito nesta área e ainda não há muito a dizer.

Representação de Documento

O HTML 5.0 introduz o conceito de serializações para um documento HTML. Uma serialização neste contexto refere-se à sua representação física. O HTML5 usa serialização HTML e o XHTML5 usa serialização XML. Devido a isso, a distinção entre um documento HTML e XHTML foi reduzida.

Há contudo, algumas capacidades que não podem ser de todo representadas. Por exemplo, os espaços de nomeção podem ser usados no DOM e na serialização XHTML mas não podem ser usados na serialização HTML.

Como consequência, isto trata do debate HTML versus XHTML de uma vez por todas. Hoje em dia muitos autores usam um DOCTYPE XHTML 1.0 e depois dizem que usam XHTML, mas na realidade usam HTML porque os navegadores tomam a decisão de tratar um documento como HTML ou XHTML baseados no tipo MIME.

Assim, ao contrário de versões anteriores, a escolha entre usar HTML ou XHTML não depende do tipo de DOCTYPE usado. Só depende do tipo MIME. Se o documento for servido como text/html, é um documento em HTML e é analisado como tal, mas se for servido com um tipo XML MIME como: application/xhtml+xml, é XHTML e é analisado como XML.

Suporte de Navegador para HTML

Na realidade analisar o HTML é um pesadelo. A web está literalmente cheia de um número infinito de páginas, número em crescimento diário e os navegadores são forçados a tratá-los todos com fineza. Não se podem permitir a darem erros independentemente do HTML ser inválido e completamente roto.

O principal problema é que há uma séria falta de interoperabilidade, que é resultante directa do facto da análise e tratamento de erros não estarem bem definidos em HTML e seguramente não definidos de um modo que seja compatível com a web.

Há também muitas extensão proprietárias que são muito usadas e bem suportadas. O problema com isto é que estas capacidades não estão bem definidas e os produtores de navegadores gastaram anos de engenharia reversa uns em relação aos produtos dos outros.

Se a engenharia reversa tivesse de algum modo sido aplicada na ajuda ao desenvolvimento de interoperabilidade entre navegadores, o processo está longe de ser perfeito e seria muito melhor se as extensões muito usadas pudessem ser bem documentadas e a interoperabilidade implementadas, que é exactamente o que o WHATWG está a tentar fazer.

Temas Relativos à Interoperabilidade

Para ilustrar a falta de interoperabilidade, vejamos um simples e comum erro de marcação e mostrar como o mesmo é tratado em diferentes navegadores. Neste exemplo os elementos strong e em foram aninhados incorrectamente.

Neste caso o Firefox e o Safari produzem o mesmo resultado, embora usem diferentes algoritmos de análise. Na representação do DOM, vejam que há 2 elemento em, embora só um surja na marcação. Para contornarem o erro de facto eles fecharam o elemento em quando o seu elemento parental fechou e criaram um novo imediatamente após.

Comparem isto com o IE, que em vez de criar 2 elementos em cria antes um DOM mal construído visto não ser estritamente uma árvore. Vejam como é que o elemento em tem 2 nós filhos, b e c, mas que o nó de texto c se refere ao elemento p como seu parental directo em vez de se referir ao elemento em.

Por último o Opera cria um DOM similar ao do IE com a excepção de que se trata de uma árvore propriamente dita. Mas o problema com esta aproximação é que o nó de texto c é um descendente do elemento strong, mas não é reproduzido como tal. Por omissão, só é reproduzido em itálicos, não a negrito, como se poderia esperar com este DOM.

Assim podem ver, com este exemplo simples, que os navegadores tratam da marcação de modo diferente. E lembrem-se que a web está cheia de um número de páginas com erros bem mais complicados do que estes.

Análise HTML 5 (só para text/html)

Em HTML, o DOCTYPE tem 2 finalidades práticas: validação e cheirar o DOCTYPE. Na actualidade a maior parte das pessoas que desenvolvem que estejam a par dos standards usam um DOCTYPE quer HTML quer XHTML, tanto Strict como Transitional. Visto o HTML 5 já não ser formalmente baseado em SGML e visto a validação baseada em DTD ter muitas limitações em relação à verificação de conformidade, o HTML 5 deixou de recomendar o uso de um DTD. Assim os verificadores de conformidade são livres de usarem a metodologia que gostarem para verificarem a validade e conformidade do documento desde que o resultado final seja o mesmo.

O DOCTYPE

Contudo há ainda questões práticas sobre como despoletar o modo standard e assim é necessário alguma forma de DOCTYPE com essa finalidade no HTML

No HTML 4, o DOCTYPE era longo e complicado com muito poucas pessoas a lembrarem-se de facto dele na totalidade. Os identificadores complexos PUBLIC e SYSTEM são usados para se referir ao DTD. Mas visto não haver DTD em HTML5 deitamos fora os identificadores PUBLIC e SYSTEM e deixamos o mínimo de código que é fácil de lembrar e despoleta o modo standard. Assim em HTML 5 o DOCTYPE é simplesmente <!DOCTYPE html>.

Isto não se aplica ao XHTML5, para o qual não há necessidade de farejar o DOCTYPE e assim não é necessário de todo o DOCTYPE.

Novas Estruturas

Actualmernte é comum usar elementos div como principais estruturas numa página, como cabeçalhos, rodapés, colunas, dando a cada uma uma id descritiva ou uma classe descritiva. Mas o seu uso deve-se à falta actual em HTML da necessária semântica para descrever estas secções.

Em casos extremos, o abuso de elementos div não semânticos pode levar ao sindrome, que é comum entre os novatos, conhecido por divitis ou divmania. O HTML5 tenta curar esta doença introduzindo novos elementos que fornecem a semântica necessária à representação de cada uma destas secções.

Há elementos novos para cabeçalho (header) e rodapé (footer) para marcarem um cabeçalhop e um rodape de uma página ou secção.

O novo elemento nav foi introduzido para criar ligações de navegação, seja navegação no sítio seja navegação na página.

O elemento (ao correr da pena) aside existe para conteúdo que tangencialmente se relaciona com o conteúdo à sua volta, usado por exemplo para marcar barras laterais.

O novo elemento (secção) section representa uma secção genérica de um documento ou aplicação, tal como um capítulo, por exemplo.

O elemento (artigo) article tal como secção, mas especificamente para marcar conteúdo como um artigo noticioso ou uma entrada num blogue.

Quando usado em conjunto com elemento de cabeçalho (hn) (onde n vai de 1 a 6), todos estes elementos dão um modeo de marcar secções aninhadas com níveis de cabeçalho, para além dos 6 níveis possíveis nas anteriores versões do HTML.

Nova Semântica

O HTML5 também introduz novos elemento para uma gama alargada de finalidades semânticas, desde simples metadados até novos widgets.

O novo elemento meter providencia um widget para representação de medidas escalares ou valores fracionários. Por exemplo, pode ser usado para mostrar a qualidade da classificação, a quota de utilização de disco ou a temperatura.

O elemento progress foi concebido para mostrar o grau de complitude de uma tarefa. Foi concebido para trabalhar com aplicações por guião que actualizem de modo dinâmico o seu progresso. Por exemplo, pode usá-la para mostrar o progresso do carregamento de uma aplicação AJAX, ou para ilustrar o progresso do utilizador no preenchimento de uma série de formulários.

O elementos canvas foi concebido para oferecer uma API 2D para desenho, especificamente para ser usada nos seus guiões. Pode ser usada para reproduzir qualquer coisas desde simples desenhos artísticos ou gráficos gerados a partir de tabelas de dados até animações ou mesmo aplicações interactivas como um jogo. Tem havido conversas sobre a introdução de uma API de desenho em 3D.

O novo elemento de (grelha de dados) datagrid representa uma representação de uma árvore, losta ou dados tabulares e oferece um widget que permite ao utilizador trabalhar os dados assim como uma API para DOM relativamente rica.

Há um novo elemento (tempo) time para marcação de datas e horas, m para realçar texto. O elemento revitalizado meu está de volta com umas melhorias, em conjunto com o elemento (comando) command, para oferecer barras de ferramentas e menus contextuais.

O muito implementado e anteriormente não documentado (embebido) embed foi introduzido, e o elemento figure permite adicionar legendas às imagens.

O elemento (detalhes) pode ser usado para representar informação adicional, disponível a pedido, e um novo elemento dialog foi feito para tornar possíveis mais interacções.

Novos Controlos

Ao longo dos anos foi tornando-se claro que os tipos de controlos disponíveis no HTML 4 eram muito limitados e forçaram alguns sítios a contornar essas limitações com graus de complexidade variável. As datas por exemplo são frequentemente pedidas usando 3 campos separados cada um deles para o dia, mes e ano. O Web Forms 2 introduziu um número de novos controlos para uma gama alargada de tipos de dados adicionais.

Há vários novos controlos para datas e horas. Este é o novo widget do Opera para o controlo de data e hora. Oferece um calendário para selecção da data e um relógio para inserção da hora. Há ainda controlos similares para a introdução só de data ou só de hora.

O novo controlo de (número) number permite a inserção de um número. A vantagem de um controlo como este é oferecer um controlo para incrementar ou diminuir o valor, assim como assegurar-se de que só é possível inserir números. Não permite a inserção de caracteres que não sejam números e assim sendo evita-se ter que se preocupar tanto com validação do lado do cliente.

Há um novo controlo disponível de (barra deslizante) slider. O ser valor também é numérico, mas foi concebido para os casos em que o valor exacto é relativamente pouco importante. Por exemplo pode ser usado para controlar coisas como volume de som ou luminosidade.

O novo controlo email foi concebido especificamente para endereços de email. A vantagem é que os navegadores podem oferecer o acesso ao livro de endereços do utilizador e também verificar se o endereço de email inserido é válido.

O novo controlod e URL também está disponível para URI. Neste exemplo o navegador listou alguns endereços correspondentes à história de navegação do utilizador.

Mas talvez a nova característica mais excitante é a capacidade de finalmente haver marcação para caixas combinadas! Estas permitem ao utilizador seleccionar algo a partir de uma lista ou inserir um novo valor. Tradicionalmente esta limitação era contornada usando-se listas de selecção separadas de caixas de texto ou simulando usando técnicas de JavaScript. Agora esta funcionalidade pode ser oferecida num único controlo.

Modelo de Repetição

Há momentos onde necessita de recolher um número arbitrário de valores para um conjunto de dados. Por exemplo, num formulário de bilhetes podemos pedir uma lista de nomes de todas as pessoas em nome das quais se está a adquirir os bilhetes, pode necessitar de adicionar contactos multiplos para um livro de endereços, ou, como no exemplo listas todos os membro do SG-1.

Nos sítios actuais normalmente exige que o utilizador submeta o formulário ao servidor usando o botão de adicionar incluído na página e o servidor responde com uma nova página actualizada com linhas adicionais. Com este novo modelo a adição ou remoção de linhas pode ser totalmente tratada do lado do cliente

A Web Forms 2.0 introduziu novas características de modelos e botões para replicação de controlos de formulário. O botão de adição pode ser usado para adicionar um novo conjunto de controlos de formulário. Neste exemplo, um quarto conjunto de campos e posição foram adicionados e preenchidos

.

Os valores podem ser facilmente removidos usando o botão de remoção. Quando o utilizador completar o formulário pode submetê-la usando o botão de submissão normal

.

O modo como isto funciona é criando marcar de modelo na página. Praticamente qualquer elemento pode ser usado no modelo, não se restringe ao uso de linhas de tabela, como no exemplo. O novo atributo (repetir) repeat indica que o elemento e respectivo conteúdo é um modelo e que pode ser replicado.

O atributo repeat-start indica quantas cópias do modelo devem ser geradas quando a página carrega, neste exemplo foram geradas 2 linhas.

Quando um modelo é replicado, é necessário ocorrerem algumas coisas. O atributo repeat recebe um índice único e o atributo repeat-template é usado para se referenciar a id do modelo a partir do qual foi criado

Note ainda os nomes dos atributos na linha modelo no final. O uso de parêntesis rectos é uma síntaxe especial que necessita de se referir às id dos modelos que sejam substituídos com o valor do índice de repetição. Deste modo pode ser usado para assegurar que cada controlo tenha um número único para ser enviado ao servidor.

Para remover blocos de repetição foi definido um novo botão remove. Quando activado, causa a remoção do seu bloco ancestral mais próximo.

Similarmente, para adicionar novos blocos de repetição existe um novo botão add. Quando activado gera um novo bloco de repetição a partir do modelo e insere-o na página.

Validação do Lado do Cliente

Na maior parte dos sítios é comum encontrarmos validação do lado do cliente concebida para auxiliar o utilizador no preenchimento de um formulário, implementada usando JavaScript. Uma das principais limitações de validação do lado do utilizador é a falta dos necessários meios nas actuais versões do HTML para descrfever um controlo de formulários com qualquer tipo de dados de validação e assim sendo, normalmente tal é alcançado completamente usando-se guiões.

O HTML5 introduziu alguns novos atributos em controlos de formulário que descrevem os valores esperados de modo a que o navevador auxilie na validação. O novo atributo required pode ser usado para indicar que o campo é de preenchimento obrigatório.

Expressões regulares, normalmente embebidas nos guiões de validação de formulários podem agora ser usados com o novo atributo pattern descrevendo exactamente qual o formato permitido. Por exemplo pode usar este padrão para restringir um campo de nome de utilizador a caracteres alfanuméricos.

Para controlos numéricos, tais como número de entre uma gama é também possível restringir os valores a valores permitidos usando os atributos de domínio min e max.

E, embora isto estivesse disponível em caixas de texto desde o princípio também as áreas de texto (textareas) vêm adicionado o atributo maxlength para não haver excesso de texto.

Os navegadores que suportem estas capacidades podem notificar o utilizador de qualquer erro e automaticamente evitar a submissão até que sejam corrigidos, ou podem ser usados em conjunto com guiões para melhorar a experiência do utilizador.

API de DOM

A acompanhar as novas capacidades de marcação que foram introduzidas o HTML5 inclui ainda novas características no DOM. O DOM é a representação interna que um navegador forma de uma página e os API que são oferecidos permitem aos guiões trabalhar com ele.

Há muitos API suportados de modo alargado em navegadorfes que anteriormente não tinham sido documentados, conhecidos como DOM level 0. Isto inclui os interfaces como Window, History, Location; e vários são suportados de modo alargado que não se encontram definidos nas especificações actuais do DOM.

Ao reconhecer o facto de que os API em causa são usados e suportados de modo alargado considera-se que é melhor documentar, standardizar e melhorá-los onde possível de modo a poderem ser implementados de modo interoperável.

Ao mesmo tempo, há várias novas capacidades em desenvolvimento. API para armazenamento do lado do cliente foi concebida para permitir aos guiões guardarem dados do lado do cliente. Deste modo são semelhantes aos cookies, mas com um API mais rico e com melhorias.

O novo interface Audio foi concebido para passar pequenos efeitos sonoros.

Há vários novos API de comunicações, incluindo eventos enviados pelo servidor, que permite a uma página receber notificações a partir do servidor quando ocorrem acontecimentos. Por exemplo poderá ser usado para acompanhar a cotação em bolsa de uma acção, sendo a mesma actualizada à medida que vai mudando.

A API de ligação de rede foi concebida para permitir aos guiões fazerem ligações TCP directas ao servidor. Isto é similar ao XMLHttpRequest, mas não está restringida só a pedidos HTTP.

E finalmente uma API para mensagens cruzadas entre documentos foi criada para que um documento possa comunicar com outro sem o aborrecimento das questões de segurança com cruzamento de domínios.

Perguntas

...

Se desejarem mais informação pode verificar o sítio do WHATWG, ler as especificações, o wiki ou a FAQ, ou ainda colocar questões na lista de correio ou nos fóruns destinados aos designer e pessoas que desenvolvem sítios.

Muito Obrigado.

Nota: O Futuro do HTML que traduzi em Novembro passado é leitura complementar.

Gapminder - Portugal - Espanha - Co2 e Urbanidade

Quem aqui venha com alguma frequência sabe que sempre gostei muito de imagens. Quando estas têm capacidades de animação ainda melhor, então se incluem estatísticas ainda melhor. O Gapminder.org tem tudo isso. hoje lá me pus a bisbilhotar dados como produção de dióxido de carbono per capita em relação à ruralidade. Para efeitos de ilustração deixo aqui os resultados para Portugal e Espanha. Só espero que haja um erro quanto à classificação de ruralidade de Portugal (só 54% de urbanos em 2002 será um dado crível, se for é uma verdadeira chatice pois então somos (e de facto somos) uns desperdiçadores de recursos.