Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

31 março, 2007

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>

26 março, 2007

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

20 março, 2007

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.

19 março, 2007

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.

O SOL é um jornal

O SOL o tal jornal que não é montra para outras coisas que é só um jornal tem um concurso para obter uma licença legal para a versão ??? do Windows Vista: Ganhe licenças Windows Vista

O jornal SOL tem para lhe oferecer licenças Windows Vista. Para as ganhar, basta ligar para o 760 300 777(custo da chamada 0.60€ + IVA)

ACM

Os resultados de um concurso entre equipas universitárias do ACM acabam de ser conhecidos. Se olharem para esses resultados vêm uma deriva para leste e oriente muito grande. O primeiro lugar foi para a Universidade de Varsóvia (Polónia) com a única equipa a responder à totalidade dos problemas. Se algum membro da imprensa ler isto pode consultar o respectivo kit

Quem pense que as universidade americanas têm os melhores alunos então vejam os respectivos resultados, só o MIT está num dos lugares cimeiros, Stanford, Carnegie Mellon, nomes que toda a gente conhece ficaram em lugares semelhantes às universidades do Rio de Janeiro e São Paulo.

Os exercícios são interessantes e deveriam ser usados/adaptados como exercícios nas nossas próprias universidades para por exemplo trabalhos de grupo.

15 março, 2007

Aquilo que não gosto no Firefox

Coisas que não consigo fazer no Firefox sem usar um rato

  • ligar e desligar o Greasemonkey
  • sair de Flash widgets (posso passar para eles [usando a tecla de tabulação] mas não consigo regressar à página novamente)
  • Não consigo fazer tabulação para sair de um campo de rtf mas posso fazer shift tab (para voltar atrás e ter o mesmo efeito

14 março, 2007

Um Outro Olhar Sobre Validação

Tradução do artigo Another Way to Look at Validation de Aaron Gustafson para o WaSP em Março de 2007

O debate sobre validação já ocorre há muito tempo, com argumentos irados de ambos os lados. No artigo de Ethan Where Our Standards Went Wrong essa discussão é reduzida a duas opiniões contrastantes.

  1. Toma a linha dura, afirmando correctamente de que se falharmos ao seguirmos as convenções de uma linguagens, então produzimos algo totalmente diferente e bem, inválido.
  2. Tem uma visão pragmática, afirmando correctamente que a geração de código inválido devido a ferramentas com erros ou código de terceiros com erros não nega o comprometimento geral de cada um com os web standards.

Depois ele pergunta "Se as duas visões são correctas, onde é que isso nos deixa?" e diz-nos que estamos num impasse.

Mais tarde no artigo, Ethan [Marcotte na A List Apart] discute modos de «vender» os standards. Faz notar por exemplo que se podem usar balas mais «sexys».

  • ciclos de desenvolvimento mais curtos
  • custos de manutenção mais baratos, e
  • peso descrecente das páginas.

Mas também lamenta as nossas falhar na venda de outras vantagens tais como:

  • acessibilidade acrescida
  • independência de dispositivo, e
  • capacidade de tornar o seu sítio à prova de futuras evoluções

O que me leva de volta à validação e de como devemos de facto usá-la para vender standards.

Ao olhar para trás no ano passado, Ethan nota que cerca de 15% do seu tempo foi gasto a contornar código inválido. Com essa descoberta conclui que os sítios "[i]nválidos podem parecer-se com os construídos com uma fundação válida, código bem formado, mas que na minha experiência invariavelmente o custo para o manter é mais elevado." Isso pode parecer óbvio para si, mas ele argumenta que não é normalmente uma característica que se venda aos nossos clientes como parte do pacote dos standards.

Quando se está a orçamentar um projecto para um cliente ou quando se discute os standards com eles, quais são as vantagens que realça? Porquê?

Seguem-se alguns dos comentários:

  1. Rick Curran diz:

    Penso que os dois pontos indicados como falhas que ele menciona são pontos importantes para a venda [dos standards]:

    • acessibilidade acrescida
    • a possibilidade de tornar o sítio à prova de futuro

    Sei que muitos clientes não se preocupam com estas coisas por acharem não terem consequências, mas trata-se realmente de tomar algum tempo para tentar e ajudá-los a compreenderem as vantagens. Tornar à prova de futuro um sítio ao torná-lo mais fácil para se adaptar a novo design mais tarde deve equivaler a uma poupança a longo prazo.

    A acessibilidade é por vezes difícil de vendas para o "homem comum" mas está a tornar-se um ponto a realçar. É aqui que o aspecto da "independência de dispositivo" (que considero parte da acessibilidade) de codificar em conformidade com um standard vale a pena para evitar ter que criar 2 versões separadas de um sítio. Novamente persuadir o homem comum das vantagens pode ser difícil.

  2. Robert respondeu:

    Não é difícil escrever código válido. É difícil levar os clientes a escreverem código válido.

    Quando codifica os seus modelos para um CMS, torne-os válidos. Se o cliente acrescentar código inválido, não há nada que se possa esperar que possa fazer. Se vendo a alguém uma arma para caça e ele assalta uma loja, não se pode esperar que eu o prenda. Se for um programador de fundo com muitos recursos, tudo o que o cliente introduza poderá ser corrido através do HTML Tidy antes de o acrescentar à base de dados. Isto pelo menos reduz a potencialidade de o seu cliente bater no 711.

    Como eu disse várias vezes, o XHTML tem o seu lugar. O HTML desculpa mais. Num sítio sobre o qual não tenha controlo sobre aquilo que um utilizador introduz é mais provável que as páginas em HTML continuem a validar. Usar HTML em vez de XHTML não significa que não está a usar Web Standards. Aplique os mesmos standards estritos aos seu código HTML como faria com o XHTML e deixe o seu cliente fazer o que ele irá fazer com o CMS.

    Se a página acabar por não validar devido àquilo que o cliente inseriu não é nada que você tenha feito como designer. Não é um erro seu; o seu comprometimento com os standards foi alcançado quando o sítio limpinho que carregou foi válido. O web design comercial não tem problemas com a validação. O conteúdo gerado pelo cliente tem problemas com a validação. Usar ferramentas para clientes, gráficas, do género do XStandards em conjunto com o HTML Tidy irão ajudar a tornar a coisa mais fácil. Alguma formação simples sobre marcação (ou a utilização de uma marcação alternativa, tal como a Markdown) pode ajudar ainda mais.

    A única outra alternativa é fazer as actualizações você mesmo para se assegurar que o sítio continua a validar. Contudo julgo que isto não é necessário. A situação não é assim tão aborrecida. As ferramentas de que dispomos podem fazer o trabalho.

  3. Peter respondeu:

    Não há nada de inerentemente errado com ter elevados ideais, mas por vezes esses ideais são irrealizáveis ou difícieis de realizar em desenvolvimento web na prática.

    O desenvolvimento baseado em standards pode promover as qualidades de perfeição, desejabilidade e excelência para o benefício de todas as partes.

    Como pessoas envolvidas no desenvolvimento, não devemos ter receio a aspirar a oferecer xhtml completamente válido por meio de ferramentas que designamos para serem o nosso CMS.

    Mas a realidade prática é a de alguém com (relativamente) pouco conhecimento, corta e cola a partir de um processador de texto para o nosso modelo válido em XHTML e a não utiliza ferramentas apropriadas para estruturar o documento antes de o publicar.

    Os Web Standards estão a tornar-se mais visíveis fora da redoma dos blogues das pessoas que produzem sítios e de sítios excelentes como este.

    A publicação na web está a mudar e os web standards estão a começar a fazer uma diferença como comunidade, cabe-nos tornar algo anteriormente idealista numa realidade pragmática.

  4. Martin diz:

    A aproximação pragmática vende sempre pois é "fazível".

    Se estamos a mudar-nos para uma visão idealista para assegurar que as páginas web sejam 100% código válido, temos que ter algumas ajudas de todos os lados tais como das ferramentas de autoria de web, cms, etc...

03 março, 2007

Matéria para a Matéria Cinzenta - Idea 2006

Eis um agregado de podcasts com o conteúdo da Idea Conference 2006 em Seatle. Esta conferência dirigia-se a arquitectos de informação e a bibliotecários (os primeiros especialistas a terem que lidar com grandes quantidades de informação e necessidades inerentes de classificação, preservação e recuperação. Nota: a conferência foi realizada na biblioteca pública desenhada por um dos discípulos de Koolhaas, e também apresentada por Prince Ramus e podemos ver o que está por detrás do conceito desta biblioteca neste vídeo:

Durante a Idea 2006 a responsável apresenta a sua visão sobre a concepção da Biblioteca.

O que é que pensam daquilo que escutaram?

02 março, 2007

Yahoo.news em gmail?

Alguém me explica esta imagem, por favor:

TDD vs BDD - Parte I

Em dezembro escrevi aqui um pequeno artigo sobre BDD - Desenvolvimento Orientado pelo comportamento e TDD - Desenvolvimento Orientado pelo Teste para melhor ilustrar a diferença hoje apresento um exemplo básico de desenvolvimento em TDD.

Os passos a seguir são:

  1. Escrever o teste
  2. Escrever a lógica
  3. Fazer a lógica passar o teste
  4. Refactorizar
  5. A cada refactorização verificar que o teste continua a ser passado
  1. Vamos pois passar ao primeiro passo escrever o teste mais simples possível. Em TDD em ruby a primeira coisa que há a fazer é criar um programa que comece por requisitar os testes unitários:

    
    require 'test/unit'
    

    Para exemplificar iremos criar um Exemplo e portanto iremos criar um teste designado por ExemploTeste:

    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def test_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
    end
    

    Corra o programa e veja o que sucede surge um relatório com o número de presunções, falhas e erros com um erro (1 presunção, 0 falhas e 1 erro).

  2. Passemos pois ao passo número 2.

    Criar a classe a testar:

    
    class Exemplo
       def initialize
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def test_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
    end
    

    Se agora corrermos o teste iremos ver que não temos erros. Passámos o teste.

    Se o programa só fizesse isto não servia para nada, por isso, imaginemos que quando um Exemplo é gerado o mesmo gera uma variável com uma string vazia. Ao teste existente acrescentamos um método:

    
    class Exemplo
       def initialize
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def test_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def teste_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
      end
    end
    
  3. Agora corremos novamente o programa teste e vemos que obtemos um erro, pois não existe variável exe na classe a testar. A nossa próxima acção é tratar de a incluir da forma mais simples para passar este teste.

    
    class Exemplo
       attr_reader :exe
       def initialize
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def testar_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def testar_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
      end
    end
    

    Executando novamente o programa vemos que ele passa sem erros mas falha! Porque falta a atribuição inicial de valor a exe. Então tratemos disso

    
    class Exemplo
       attr_reader :exe
       def initialize
         # a arroba denota que é uma variável de instância
         @exe = ""
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def testar_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def testar_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
      end
    end
    

    Agora se correr o programa este passa sem erros nem falhas. O programa evoluíu um pouco. Mas se uma variável não pudesse mudar de valor de pouco servia, vamos pois tentar criar um teste para a mudança do seu valor.

    
    class Exemplo
       attr_reader :exe
       def initialize
         # a arroba denota que é uma variável de instância
         @exe = ""
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def testar_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def testar_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
        ex.exe = "Olá moça!"
        assert_equal("Olá moça!",ex.exe)
      end
    end
    

    Se corrermos o programa ele terá uma falha pois não há forma de mudar o valor. Então tratemos de o fazer.

    
    class Exemplo
       attr_reader :exe
       attr_writer :exe
       def initialize
         # a arroba denota que é uma variável de instância
         @exe = ""
       end
    end
    
    require 'test/unit'
    
    class ExemploTeste < Test::Unit::TestCase
      def testar_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def testar_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
        ex.exe = "Olá moça!"
        assert_equal("Olá moça!",ex.exe)
      end
    end
    
  4. Agora já não temos nem erros nem falhas. Passamos o teste. Então chegou o momento de refactorizarmos a nossa classe Exemplo:

    
    class Exemplo
       attr_accessor :exe
    
       def initialize
         # a arroba denota que é uma variável de instância
         @exe = ""
       end
    end
    class ExemploTeste < Test::Unit::TestCase
      def testar_initialize
        ex = Exemplo.new
        assert_not_nil(ex)
      end
      def testar_exe
        ex = Exemplo.new
        assert_equal("",ex.exe)
        ex.exe = "Olá moça!"
        assert_equal("Olá moça!",ex.exe)
      end
    end
    
  5. Voltamos a correr o teste e podemos comprovar que a nossa refactorização correu bem.

Recursos em inglês

Novas Profissões

De acordo com Web Worker estão à disposição cinco novas profissões geradas pelo mundo digital.

  1. Produtor de Novos Meios -- Género Ask a Ninja ou RocketBoom.
  2. Artesão de Legendagem de Roupas -- Género Lactivist.
  3. Microinvestidor -- Género prosper.
  4. Editor -- Tirando partido de serviços como a lulu.
  5. Curador Comunitário -- Usando sítios como o ning.com

Second Life no Público e AdaptivePath

Hoje o Público (edição em papel) tem uma tradução de um artigo do LA Times sobre a perca da inocência no Second Life. Como leitor atento do blogue da Adaptive Path tenho vindo a acompanhar uma série (ainda pequena) de artigos relativos às entrevistas conduzidas por Chiara Fox e Andrew Crow numa sala devidamente preparada pelo Linden Lab.

Já agora o quartel-general, da campanha do John Edward, foi vandalizado no Second Life.

01 março, 2007

Diambulações

Hugo Neves da Silva no seu Lisbon Lab tem um conjunto de entrevistas, que designa por BloggerView, muito interessantes.

Tim Berners-Lee testemunhou no Congresso Americano como períto sobre o futuro da www.

Porque é que não escrevo em inglês tem que ser actualizado.

Porque o meu conhecimento de inglês não chega aos pés do Language Log. Já agora este é um dos sítios de que assinei o respectivo alimento. É bom para aprender algo sobre a língua inglesa.

Address, o elemento esquecido?

Há uma lista de elementos HTML que estão mal representados na generalidade da marcação usada actualmente na web. Vários destes elementos têm maior valor semântico que o que actualmente é aplicado, mas com o aumento da popularidade do design orientado pelo CSS com os elementos HTML a serem usados para o que foram concebidos julgo que seria bom expôr estes elementos indicando em que situações seriam úteis. Um desses elementos é o elemento address:

<address>

O marcador <address> foi concebido para conter informação sobre endereços, assinatura e autoria. Números de telefone, fax, endereços físicos, endereços de correio electrónico, ICQ/Gtalk... ou qualquer outros dados de contacto em linha e fora dela são todos válidos. Normalmente os elementos <address> encontram-se no topo ou na parte de baixo do documento.

Utilização:

<address>
O Nome da entidade <br />
Rua do Mistério, 126 <br />
1025 Lisboa <br />
Telefone: 21 000 0000 <br />
Fax: 21 00 0001
</address>

Para quê? Posso fazer o mesmo com um marcador <div>

Os elementos agrupados com um <div> não têm valor semântico excepto se lhes for atribuída uma identificação ou classe. Então porquê criar uma <div class="contacto"> quando já há um elemento que o pode fazer?

Exemplo:


address {
  background-color: #dfd;
  padding: 4em 0 4em 4em;
  font-style: normal;
}

...

<address>
<a href="http://aindaapensar.blogspot.com">Carlos</a>
<br />
NaoSeTrataDeNenhumaInstituição <br />
Rua da Estória, 23424 <br />
1025 Lisboa

O resultado:

Carlos
NaoSeTrataDeNenhumaInstituição
Rua da Estória, 23424
1025 Lisboa

Joost

A última actualização ocorreu em 2007-05-01.

O Joost acaba de me enviar uma mensagem dizendo-me que tenho mais alguns convites disponíveis para quem queira testar este novo sistema de ver TV. Os poucos leitores deste blogue que queiram experimentar podem pedir um nos comentários. Este serviço Joost exige banda larga e um computador que não seja um molenga a contrapartida é poder aceder-se a alguns programas de televisão com boa qualidade. O interface é diferente do de uma televisão. Toma por defeito a totalidade do ecrã mas pode ser posto a correr numa janela. Há versões para Windows e para Mac.

--Completamente fora de tópico.

De momento já não tenho convites para enviar Para a Anna e outros leitores, de momento não tenho convites. A recusa do vosso comentário é só para evitar poluir excessivamente o blog. Quando e se tiver convites volto a contactar. Volto hoje, 2006-04-26 a ter 4 convites disponíveis. Agradecia que quem pedisse um convite me fizesse chegar um comentário com: aliteração (alias) nome (nome próprio), apelido (sobrenome), e mail válido agradecia que não o ofuscassem em demasia. Em vez de publicar os comentários passarei a colocar um comentário eu mesmo com a aliteração ou caso não seja enviado com o nome próprio da pessoa que pede. Isto evitará que eu atribua um nome à pessoa. O mail tem que ser válido para a joost poder confirmar a v. inscrição. Houve dia 27 de Abril quem tenha pedido um convite, só não tenho dados válidos para lho puder enviar.