Subject: Resumo XML
Date: Thu, 26 Mar 1998 16:57:00 -0300
From: Jose Roberto Vasconcelos <jrvascon@dca.fee.unicamp.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
Resumo da discusao em sala de 26/03/98.
grupo A
Itens discutidos :
1) Aplicacao:
Ambiente de autoria, em que o usuario pode utilizar-se de bases de
dados heterogeneas, para obtencao de informacoes que contribuam para a
producao de seu material.
2) Funcoes requeridas pela aplicacao:
Permissao para acesso (consulta) a diversas informacoes, para producao
do material final, possibilitando a utilizacao de links multiplos ou
links para bases de dados com diversas estruturas, com a possibilidade
de incorporar a informacao recuperado no documento final.
3) Vantagens para a aplicacao:
Facilidade para a geracao de material para educacao, fazendo uma
incorporacao de materiais, como a composicao de um livro feito atraves
da juncao de varias partes.
4) Suporte do XML versus restricoes de HTML.
a) na descricao da estrutura da base de dados permissao ao cliente
pesquisas sobre a estrutura da base requerendo independencia da
tecnologia utilizada por esta;
b) permitir navegacao da estrutura sob a visao do cliente;
c) atraves do link bidirecional proporcionar ao cliente estar sempre
atualizado a respeito da estrutura da base.
d) num ambiente de autoria facilidade de incluir as informacoes
obtidas no documento produzido, atraves de transclusao.
Relator: Jose Roberto Vasconcelos
Subject: Re: Resumo XML
Date: Thu, 26 Mar 1998 17:25:57 -0300
From: "Flavia Torres" <flavia@ic.cti.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
References: 1
Grupo B - Itens discutidos em sala:
Cenário para uma aplicação de Educação onde o trabalho de processamento
das informações deve ser dividido entre o Servidor e o Cliente Web.
Ambiente: sala de aula
Atores: alunos e instrutores
Recursos XML x Restrições do HTML (dentro desse contexto):
A - Criação de marcadores personalizados.
O XML fornece a possibilidade de criação de novos marcadores (TAGS) de
acordo com a aplicação. Podem ser criados TAGS relacionados com a base de
dados utilizada. Aplicada à educação pode-se criar TAGs para ,
, , , etc.
B - Independência de plataforma e vendedor.
XML é independente da plataforma utilizada. HTML depende do cliente e do
servidor Web que está sendo utilizado.
C - Processamento no cliente.
XML permite conexão contínua entre cliente e servidor. No HTML após uma
página ser carregada a conexão é desfeita e para um novo acesso é necessário
o estabelecimento de uma nova conexão.
A idéia é realizar o processamento no cliente cabendo ao servidor apenas
o fornecimento dos dados. Para processamentos mais complexos é necessária
uma conexão contínua entre servidor e cliente para que não haja quebras
durante a comunicação.
Subject: Re: Resumo XML
Date: Thu, 26 Mar 1998 19:51:40 -0300
From: "Flavia Torres" <flavia@ic.cti.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
References: 1 , 2
Desculpe-me. Esse resumo foi elaborado pelo grupo C:
Carlos Dagnone
Marcia Pimenta
Marcelo Morandini
Maria Flavia Torres (redatora)
e não pelo grupo B como escrito abaixo.
Flavia Torres wrote in message <6feh4o$8m6$1@peninha.fee.unicamp.br>...
>Grupo B - Itens discutidos em sala:
>
> Cenário para uma aplicação de Educação onde o trabalho de processamento
>das informações deve ser dividido entre o Servidor e o Cliente Web.
> Ambiente: sala de aula
> Atores: alunos e instrutores
>
> Recursos XML x Restrições do HTML (dentro desse contexto):
>
....
Subject: Resumo XML
Date: Thu, 26 Mar 1998 19:59:15 -0300
From: "Fabricio L. F. Cabral" <fcabral@dpi.ufv.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
IA368F – Tópicos em Engenharia da Computação V
XML
Grupo G3
Rossano Pablo Pinto – 973273 (Relator)
Luciana Meneghel – 973271
Maria Fernanda – 983833
Marcelo Tilli – 973624
Segundo Connolly[2], o XML facilitará o encontro dos "geradores" de
informação e as pessoas que a buscam, e também desempenhará importante
papel em aplicações baseadas na WEB, pois o XML permite a representação de
"informação" sobre a informação propriamente dita, ou seja, informação
adicional que não será vista ou utilizada pelo usuário e sim por agentes
inteligentes, ou aplicações diversas. Bosak[1] argumentou que as aplicações
que fariam com que o XML fosse aceito, seriam aquelas as quais o HTML não
dá suporte. Estas foram divididas em 4 categorias:
1.Aplicações que necessitem a mediação do cliente entre duas bases de
dados heterogêneas.
2.Aplicações que tentam distribuir uma significativa proporção do
trabalho do servidor WEB para o cliente.
3.Aplicações que necessitam apresentar diferentes vistas dos mesmos
dados à diferentes usuários.
4.Aplicações nas quais Agentes Inteligentes da WEB tentam moldar a busca
de informações às necessidades de usuários individuais.
A quarta categoria será o alvo da discussão deste documento.
Agentes da WEB (dados que conhecem o usuário)
Bosak[1] argumenta que um futuro domínio para aplicações XML surgirá quando
os agentes inteligentes da WEB começarem a requisitar maior estruturação
dos dados, necessidade resumida pela frase de Mathew Fuchs -"A informação
precisa conhecer a sí mesma, e também me conhecer".
Para definir uma aplicação de educação na categoria 4, definiremos o seguinte cenário:
Atores: Alunos de Ciência da Computação
Ambiente: Laboratório de microcomputadores com conexão à Internet.
Tarefa: Pesquisar na Internet o assunto "Vírus de computador".
Baseado no cenário acima, um agente inteligente de busca da WEB não seria
capaz de executar uma busca eficiente em documentos escritos em HTML, pois
este último não permite definir o conteúdo de um documento segundo o perfil
do usuário que poderia acessá-lo, ou mesmo o assunto do documento. A busca
provavelmente traria muita informação sem utilidade para o grupo de alunos,
muitas delas relacionadas à área de biologia e não da computação, como era
esperado. A não extensibilidade do HTML não permite a criação de novos
"tags", impossibilitando a especificação de um documento a ponto de
especializá-lo à uma determinada área.
O XML superaria as restrições acima citadas e permitiria aos agentes
inteligentes maior eficiência na execução de suas tarefas, pois o XML daria
subsídios para disponibilizar mais informação sobre cada documento
produzido.
Subject: XML - Resumo: grupo E
Date: Thu, 26 Mar 1998 17:02:43 -0300
From: Daniela Barbetti <daniela@ccuec.unicamp.br>
Organization: UNICAMP - Centro de Computacao
Newsgroups: feec.posgrad.IA368F
Grupo E: Adriana, Christian, Daniela, Marcelo e Ricardo (relator)
Aplicação de consulta e manipulação de dados em uma biblioteca
- o material da biblioteca estaria disponível em documentos XML;
- identificação/perfil/interesse do usuário
restrições do html: a decisão do conteúdo que o usuário vai
enxergar é feita no servidor (não implementa TOCs)
- anotações em relação ao material de pesquisa;
- restrições do HTML de forma geral:
. não possui redefinição de tags;
. não suporta especificação de estruturas complexas;
. não possui tecnologia de links bidirecionais e o conceito de
links-entidades;
. visão de layouts: o HTML não possue suporte de uma linguagem
de marcação estruturada e extensível que permita a utilização
de técnicas de "renderizar". Para uma aplicação XML foi
definido um subconjunto do DSSSL (Document Style Semantics
and Specification Language).
--
Daniela Regina Barbetti
State University of Campinas - Computer Center
Phone: (55) 019-788.2246 - Fax: (55) 019-289.2577
------------------------------------------------------------
mailto:daniela@ccuec.unicamp.br
http://www.ccuec.unicamp.br/funcionarios/265420.html
Subject: resumo XML grupo F
Date: Thu, 26 Mar 1998 19:16:27 -0300
From: Raquel Santos Schulze <raquel@dca.fee.unicamp.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
CC: raquel@dca.fee.unicamp.br
Newsgroups: feec.posgrad.IA368F
DEFINA UMA APLICACAO DE EDUCACAO NA CATEGORIA ACIMA, QUE EXPLORE OS
RECURSOS DE XML. COMENTE AS RESTRICOES QUE HTML IMPORIA.
APLICACAO:
Sistema de apoio a pesquisa bibliografica para Estudos Especiais cujos
usuarios finais serao os alunos de pos-graduacao, i.e., mestrado e
doutorado.
Esse sistema deveria ser capaz de identificar as seguintes
caracteristicas de cada aluno: nome, orientador, projeto, assuntos de
interesses relacionados a tema de tese objetivando o correlacionamento
personalizado das descobertas de informacao com as necessidades de cada
usuario.
AGENTE:
A implementacao desse sistema sera baseada em agente, que ira receber,
analisar e interpretar as necessidades de cada usuario. E atraves desse
mecanismo agente que sera possivel personalizar as solicitacoes dos
alunos uma vez que esse agente sera dotado de inteligencia,i.e.,
capacidade de tomar decisao baseado em um conjunto de informacao
previamente conhecido.
CARACTERISTICAS DESEJAVEIS DO AGENTE:
.Busca estruturada
.Busca bidirecional
POR QUE NAO O HTML
HTML e uma linguagem razoavelmente boa para implementaccoes de
aplicacoes co hipertexto e multimidia, ams para documentos relativamente
pequenos e simples.
Na nossa aplicacao, o uso de HTML nao e aconselhavel pelas seguintes
razoes:
.O conjunto de "tag" HTML e muito limitado para representar ou
diferenciar os diversos campos de uma base de dados;
.O HTML e incapaz de representar a variedade de estrutura de documentos
complexos;
.O HTML nao possui mecanismo para verificacao dos dados quanto a
validade estrutural na insercao de dados na base de dados.
POR QUE XML:
.XML difere de HTML nos tres aspectos principais:
1.Fornecedores de informacao podem definir novo "tag" e nomes de
atributo quando desejado.
2.Estruturas de documentos podem ser aninhadas a qualquer nivel de
complexidade.
3.Qualquer documento XML pode conter uma descricao opcional de sua
gramatica para ser usada por aplicacoes que necessitam fazer validacao
estrutural.
.XML oferece mecanismos avancados de "linking" e "stylesheet"
"linking":.Nomeacao independente de localizacao
."Links" bidirecionais
."links" que podem ser especificados e gerenciados fora
dos documentos aos quais eles aplicam.
."N-ary hyperlinks" (e.g., rings, multiple windows)
."Links" agregados (multiple sources)
."Transclusion" (o "link" do documento alvo aparece como
parte do "link" do documento fonte)
"Stylesheets"
O complemento para XML e uma linguagem de programacao "stylesheet" que
e:
.Estendida livremente de maneira que projetistas possam definir um numero
ilimitado de tratamento para uma variedade ilimitada de "tags".
."Turing-complete" de maneira que projetista de "stylesheet" possam
arbitrariamente estender as procedures disponiveis.
.Baseada em uma sintaxe padrao para minimizar a curva de aprendizado.
.Capaz de enderecar a estrutura de arvore inteira de um documento XML em
termos estruturais, de maneira que relacionamentos de contexto entre
elementos em um docuemnto possam ser expressos em qualquer nivel de
complexidade.
.Completamente internacionalizado de modo que "scripts"
esquerda-para-direita, direita-para-esquerda e alto-para-baixo possam todos
ser tratados, mesmo que misturados em um unico documento.
.Provida de modelo de entrega (rendering model) que permite a especificacao
de caracteristicas de "layout" de pagina profissional tais como "multiple
column sets", "totated text areas" e "float zones".
.Definida de uma maneira que permita "rendering" parcial para "rendering"
parcial de documentos pela Web.
Raquel
Subject: XML - resumo
Date: 26 Mar 1998 23:42:28 GMT
From: "Cesar C. Cardieri" <veca@so.dglnet.com.br>
Organization: Homr Office
Newsgroups: feec.posgrad.IA368F
Aspectos discutidos em classe (26/03/98)
grupo B - Antonio Tadeu
Jefferson
Maria das Graças
Maria Angélica
Item de discussão: Aplicações que tentam distribuir uma significante carga
de processamento do web server para o web cliente.(2)
Aplicação definida: Pesquisa bibliográfica onde existem várias fontes a
serem consultadas(bibliotecas,institutos de pesquisas, etc) e os documentos
possuem formato e estrutura diferentes.
Vantagens da utilização de XML:
-Documentos distribuidos em diversos locais podem ser enviados de forma
parametrizada, isto é customizados através de um conjunto de tags e
enviados ao cliente juntamente com applets java de forma a serem
manipulados de diferentes maneiras no cliente distribuindo o
processamento. Um exemplo de manipulação seria pesquisas semânticas dentro
de uma área específica.
-Execução independente de plataforma
Restrições que a HTML imporia:
- HTML não consegue ler padrões diferentes devido à existencia de um
conjunto fixo de tags.
- Não consegue manipular estrutura de dados.
Subject: Resumo grupo D3
Date: Fri, 27 Mar 1998 01:10:41 -0300
From: José Estevão Picarelli <estv@uol.com.br>
Organization: PUC-Campinas
Newsgroups: feec.posgrad.IA368F
XML, aplicação na Web, requisito "Diferentes Visões" e Educação
Grupo D3 (Estevão, Ivan, João Orosz, Ricardo C. e Márcio)
Sumário:
Introdução
.aplicações na Web
.interesse da educação
.XML para atender requisitos hoje não atendidos
Definições
Aplicações na área de educação
.lista de aplicações
.destaque do requisito várias visões
XML, alternativa para imlementaçào
. recursos (extensibilidade,estruturacão, validação)
.características e princípios gerais
Conclusão
Referências
Subject: Resumo XML - G3
Date: Fri, 27 Mar 1998 08:42:47 -0300
From: Ivan Luiz Marques Ricarte <ricarte@dca.fee.unicamp.br>
Organization: Universidade Estadual de Campinas - UNICAMP
Newsgroups: feec.posgrad.IA368F
IA368F - Tópicos em Engenharia da Computaçao
Grupo G3
Rossano Pablo Pinto - 973273 (Relator)
Luciana Meneghel - 973271
Maria Fernanda - 983833
Marcelo Tilli - 973624
Segundo Connolly[2], o XML facilitará o encontro dos "geradores" de
informação e as pessoas que a buscam, e também desempenhará importante
papel em aplicações baseadas na WEB, pois o XML permite a representação
de "informação" sobre a informação propriamente dita, ou seja,
informação adicional que não será vista ou utilizada pelo usuário e sim
por agentes inteligentes, ou aplicações diversas. Bosak[1] argumentou
que as aplicações que fariam com que o XML fosse aceito, seriam aquelas
as quais o HTML não dá suporte. Estas foram divididas em 4 categorias:
1. Aplicações que necessitem a mediação do cliente entre duas bases de
dados heterogêneas.
2. Aplicações que tentam distribuir uma significativa proporção do
trabalho do servidor WEB para o cliente.
3. Aplicações que necessitam apresentar diferentes vistas dos mesmos
dados à diferentes usuários.
4. Aplicações nas quais Agentes Inteligentes da WEB tentam moldar a
busca de informações às necessidades de usuários individuais.
A quarta categoria será o alvo da discussão deste documento.
Agentes da WEB (dados que conhecem o usuário)
Bosak[1] argumenta que um futuro domínio para aplicações XML surgirá
quando os agentes inteligentes da WEB começarem a requisitar maior
estruturação dos dados, necessidade resumida pela frase de Mathew Fuchs
-"A informação precisa conhecer a sí mesma, e também me conhecer".
Para definir uma aplicação de educação na categoria 4, definiremos o
seguinte cenário:
* Atores: Alunos de Ciência da Computação
* Ambiente: Laboratório de microcomputadores com conexão à Internet.
* Tarefa: Pesquisar na Internet o assunto "Vírus de computador".
Baseado no cenário acima, um agente inteligente de busca da WEB não
seria capaz de executar uma busca eficiente em documentos escritos em
HTML, pois este último não permite definir o conteúdo de um documento
segundo o perfil do usuário que poderia acessá-lo, ou mesmo o assunto do
documento. A busca provavelmente traria muita informação sem utilidade
para o grupo de alunos, muitas delas relacionadas à área de biologia e
não da computação, como era esperado. A não extensibilidade do HTML não
permite a criação de novos "tags", impossibilitando a especificação de
um documento a ponto de especializá-lo à uma determinada área.
O XML superaria as restrições acima citadas e permitiria aos agentes
inteligentes maior eficiência na execução de suas tarefas, pois o XML
daria subsídios para disponibilizar mais informação sobre cada documento
produzido.
Subject: Tema 1
Date: Wed, 01 Apr 1998 11:19:08 -0300
From: Valmir Tadeu Fernandes <valmir@dsce.fee.unicamp.br>
Organization: DSCE - FEEC - UNICAMP
Newsgroups: feec.posgrad.IA368F
Tema 1
Funcionalidade do ambiente "Curso sob medida + Prova virtual".
Cenário
Uma disciplina é ministrada em vários cursos, sendo especialista para cada um deles.
a - Terminologia :
Universidade é composta por unidades (Faculdades e Institutos) que
são responsáveis por cursos oferecidos ( Eng. Computação,
Eng. Química). Cada curso possui uma grade curricular com varias
disciplinas. Existe interseção das disciplinas em diferentes cursos, ( por
exemplo cálculo p/ Eng. Civil e Eng. Materiais).
b - Segurança :
Deve ser considerada em todas as etapas a funcionalidades descritas.
c - Funcionalidade :
1 - Compor as disciplinas ( material, exercícios, provas, aulas,
grupos de forma distribuida, etc..
2 - Estabelecer perfis para cada curso (definir diferentes visões).
3 - Cadastra atores com diferentes perfis e níveis de acesso
(instrutor, monitor, alunos, grupos de forma distribuída).
4 - Disponibilizar as disciplinas/aulas (Relacionamento
curso/aulas/disciplinas/tempo máximo).
5 - Acompanhar o andamento da disciplina.
Fornecer feed-back para alunos e professores.
6 - Aplicar prova ( testes, dissertativas, etc...).
7 - Corrigir e pontuar a prova
Pelo próprio sistema ( testes).
Instrutor "ad-hoc".
Auto-correção (disponibilizar gabaritos para auto avaliação.
8 - Disponibilizar resultados.
Subject: XML - Tema 2
Date: Wed, 1 Apr 1998 10:44:59 -0300
From: "Flavia Torres" <flavia@ic.cti.br>
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
Tema 2 - Arquitetura do Sistema
Integrantes do grupo:
Carlos Augusto Fernandes Dagnone
Marcelo Morandini
Marcia F. Pimenta
Maria Flávia Cunha F. Torres
Sergio Luiz Moral Marques
1- Browser: necessário para consulta do material pelos alunos, resolução
das provas pelos alunos, avaliação das provas pelo instrutor.
2- Servidor Web.
3- Base de dados heterogênea, distribuída e transparente para o cliente.
Como a aplicação será usada por vários institutos distintos de uma
Universidade, os dados podem estar distribuídos nos diferentes servidores de
cada unidade.
4- Servidores de banco de dados.
5- Mecanismos de busca (agentes "inteligentes"): necessários para
montagem das provas de acordo com o grau e curso do aluno, montagem das
matérias disponíveis nas disciplinas de acordo com o curso referente.
6- Ferramentas de apoio ao aluno como calculadoras, editores de
gráficos, etc.
Subject: Curso sob medida+Prova virtual - Tema 3: Aspectos de implementação com HTML
Date: Wed, 01 Apr 1998 11:32:25 -0300
From: Armando Luiz Nicolini Delgado <delgado@dca.fee.unicamp.br>
Organization: Departamento de Informatica - UFPR
Newsgroups: feec.posgrad.IA368F
Especificação de um Ambiente para Cursos sob Medida com Provas Virtuais
GRUPO 3 - Aspectos de Implementação com HTML/WWW
Membros: Alberto Barbosa Raposo, Armando Luiz N. Delgado, José Roberto
Vasconcelos, Luiz Gonzaga da Silveira Júnior, Marcos Lordello
Chaim
Premissas: Os aspectos de implementacao discutidos aqui se baseiam nas
discussões sobre a funcionalidade do sistema e sobre a a
arquitetura do mesmo ocorrido na plenária sobre XML.
Infraestrutura:
1. Cadastramento do ator: (RA, nivel de acesso, senha, disciplina, perfil)
armazenado em banco de dados em um servidor;
2. Material de disciplina: (provas, exercícios, notas de aula,
hiperdocs principais, hiperdocs específicos de cada perfil ou
contexto) armazenados em bancos de dados centralizados ou não.
Funções:
1. Identificação do ator para acessar material do curso feita através
de HTML forms, com informações autenticadas na servidor;
2. Hiperdocs principais são páginas HTML que, em pontos específicos,
possuem referências a hiperdocs dependentes do contexto, de forma
que no momento da apresentação do hiperdoc final forneça a VISÃO do
hiperdoc adequada ao ator que a visualiza. As referências ao
hiperdoc específico deverão ser feitas através de CGI Scripts;
Estes scripts CGI devem ser concebidos de forma a consultar o banco
de dados pelos hiperdocs específicos, levando em conta o PERFIL
associado ao ator;
3. Todo hiperdoc deve ter um link para permitir a entrada de ANOTAÇÕES
do ator (via HTML forms). Estas anotações devem ser armazenadas
como páginas HTML na área de trabalho do ator;
4. Todo hiperdoc deve ter um link para permitir a entrada de DÚVIDAS do
ator (via HTML forms). Estas anotações devem ser armazenadas no
banco de dados do servidor, para formar um conjunto de FAQ's, a ser
analisado e compilado pelos autores ou instrutores, que devem ter
uma ferramenta auxiliar de manipulação do BD para fazer consultas e
manipulações nos dados;
5. As atividades práticas (exercícios, provas, trabalhos, etc.) estão
armazenadas em 2 bases de dados. A primeira contém os enunciados
existentes com os seguintes parâmetros: enunciado de questão,
perfil, identificação do enunciado, disciplina, resposta correta
(não acessível por alunos).
A segunda base de dados contém a especificação do exercício,
contendo: identificação do exercício, identificação dos enunciados
que compõem o exercício, tempo máximo para resolução do exercício
(expresso em minutos, dias ou data), permissão para interrupção de
tempo de resolução.
Existe ainda uma terceira base de dados que armazena: identificação
do aluno, resposta do aluno, tempo gasto para responder e nota.
Quando um aluno consulta o exercício, são apresentadas a ele as
questões associadas ao exercício, de acordo com o perfil do aluno.
As questões são apresentadas utilizando-se applets Java, de forma
que o controle de tempo possa ser feito localmente e de modo seguro.
A permissão para interrupção indica se o aluno pode interromper a
resolução ou se, uma vez iniciada a resolução do exercício, ele deve
resolvê-lo sem interrupção.
Em cada questão, o aluno sinaliza o término da resposta. O applet
então contabiliza o tempo, e envia resposta da questão e tempo de
volta ao servidor.
Quando o aluno terminou todas as questões, ou se ele sinaliza que
terminou a prova, o applet deve coletar todas as respostas que não
foram enviadas, juntamente com seus tempos.
Estes dados serão armazenados em uma base de dados associada ao
aluno. Assim, na página apresentada ao aluno, existem elementos
para sinalizar final de resolução e interrupção de resolução (se
assim for permitido).
Ao aluno é permitido escolher a questão a resolver, na ordem em que
quiser.
O applet java deve ser feito de forma que, ao findar o tempo de
resolução, o aluno é avisado e a página é fechada e os dados
enviados ao servidor.
Quando o aluno finaliza prova, ele recebe de volta uma página com a
cópia da prova como foi armazenada no servidor, com o tempo total de
resolução. Isto serve como recibo para o aluno.
5. A correção da prova pode ser automática ou não, dependendo do tipo
de questão apresentada. Cabe ao servidor ter implementada alguma
ferramenta do tipo.
Qualquer página apresentada ao ator, se envolve uma consulta a um
banco de dados implica na página uma referência a um script CGI ou (no
caso de exercícios) a execução de um applet Java. A linguagem HTML
oferece os recursos básicos de formatação e referência a links, mas a
necessidade de composição de documentos em um só (visão) necessária
somente pode ser provida por CGI.
Subject: Re: Tema 4 (fwd)
Date: Tue, 31 Mar 1998 14:13:50 -0800
From: Antonio Tadeu Maffeis <maffeis@splicenet.com.br>
Organization: Antonio Tadeu Maffeis
Newsgroups: feec.posgrad.IA368F
------------------------------------------------------------------|
Tema 4: Aspectos da implementação em XML/WWW (futuro) |
------------------------------------------------------------------|
Integrantes do grupo
-------------------------
819815 Maria Angelica Calixto de A. Cardieri
955224 Naur João Janzantti Júnior
956289 Raquel Santos Schulze
961384 Maria das Graças Junqueira M Tomazela
972407 Firmiano Ramos Perlingeiro
973271 Luciana Meneghel
973273 Rossano Pablo Pinto
973505 Raquel Cristina Bosnardo
973528 Jefferson Blaitt
973529 Antonio Tadeu Maffeis (Relator)
983833 Maria Fernanda Bionafina Nogueira
Cenário:
--------
Um a disciplina é ministrada em vários cursos sendo especializada para
cada um deles. A avaliação dos alunos será feita via "prova virtual".
Aspectos funcionais da aplicação:
---------------------------------
- Os instrutores podem preparar todo material da disciplina
identificando quais pontos seriam relevantes ser abordados em cada curso
(referências, notas de aula, avaliações, etc.);
- Provas devem ter um tempo máximo para serem realizadas, bem como
cada questão;
- Os alunos devem ser autenticados para terem acesso ao
material/avaliações relativos a disciplina que estejam cursando;(segurança)
OBS.: não estão sendo considerados aspectos relativos a procedimentos
administrativos, como por exemplo matrícula dos alunos, divulgação da lista
dos aprovados, etc.
Aspectos da Implementação em XML/WWW
------------------------------------
A atividade de co-autoria (planejamento e preparação do material
pelos instrutores) poderá ser facilitada, uma vez que XML suporta a criação
de TAGs, tendo assim uma linguagem markup adequada as necessidades dos
autores e podendo-se assim, com estes TAGs, criar diferentes níveis de
profundidade ou diferentes abordagens para o mesmo tema.
O acesso a informações em base de dados distintas (heterogêneas) pode ser
implementado com o XML sem necessidade de existir, por exemplo, scripts
CGI; no próprio documento você pode ter comandos de acesso aos banco de
dados (comandos SQL embutidos no documento XML). Isto facilitaria tanto a
identificação do aluno, como a busca de "informações" que irão compor
o documento.
Um exemplo de sintaxe do XML seria:
<!ELEMENT group (document *)>
<!ATTLIST group
xml:link CDATA #FIXED "group"
steps CDATA #IMPLIED\>
<!ELEMENT document EMPTY>
<!ATTLIST document
xml:link CDATA #FIXED "document"
%locator.att;
>
A personalização das "informações" que serão exibidas aos usuários
pode ser obtida através da especialização dos LINKS e do recurso de
transclusão, isto é, a informação que será exibida depende do curso o aluno
pertence (Eng. Elétrica, Química, etc.). A utilização de links
multidirecionais melhoraria o resultado da busca da informação uma vez que
permitiria buscas multidirecionais também. Observe a implementação abaixo:
<!ENTITY % remote-resource-semantics.att
"role CDATA #IMPLIED
title CDATA #IMPLIED
show (embed|replace|new) #IMPLIED
actuate (auto|user) #IMPLIED
behavior CDATA #IMPLIED"
>
É possível implementar então o papel do recurso, o título do recurso e as
políticas de comportamento a serrem usadas quando percorrendo esses
recursos.
As provas também serão personalizadas e levarão em consideração o
critério tempo com uma variável da questão ou da prova, sendo que um agente
poderá utilizar esta informação para invalidar a questão ou a prova caso o
aluno tenha excedido seu tempo. Outro item também relacionado a prova será
a validação da questão, que poderá ser realizada no próprio cliente, sem
ter a necessidade de se enviar os dados para serem validados num servidor
via CGI.
Subject: Re: XML - Tema 2
Date: Mon, 06 Apr 1998 15:20:42 -0300
From: Adriana Delfino dos Santos
Organization: CNPTIA/EMBRAPA
Newsgroups: feec.posgrad.IA368F
Pessoal,
Sobre arquitetura do sistema, eu esperava que fosse definido COMO
as funcionalidades especificadas para o sistema podem ser implementadas.
O grupo que discutiu este tema apresentou um esquema e acho que as considerações
que faço abaixo poderiam enriquecê-lo. Relaciono algumas da funcionalidades e a
minha visão de como implementá-las.
Por favor, se estiver enganada, me corrijam.
Adriana
Subject: Relatorio Final Formato de Documentos na Web - Comentarios
Date: Mon, 13 Apr 1998 08:30:23 -0300
From: Marcos Lordello Chaim
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
Pessoal,
Na minha opiniao as secoes "Aspectos de Implementacao com HTML/WWW"
e "Aspectos de Implementacao em XML/WWW" misturam questoes de
funcionalidade com as de implementacao.
Acredito que as secoes "Funcionalidade" e "Arquitetura" devem definir
as funcionalidades e a arquitetura (um ou mais servidores,
base de dados centralizada x distribuida, estrutura de dados etc.),
utilizando alguma forma de referenciacao. As demais secoes
simplesmente fariam referencia a elas.
Acho que ha' alguns termos sem a devida explicacao. Por exemplo,
quando se fala em "mecanismos de busca" ("agentes inteligentes").
Nao sei o que sao "Agentes Inteligentes". Creio que o texto
deva explica-lo brevemente.
Marcos L. Chaim
Subject: Re: Relatorio Final Formato de Documentos na Web - Comentarios
Date: Mon, 13 Apr 1998 12:50:33 -0300
From: Adriana Delfino dos Santos
Organization: CNPTIA/EMBRAPA
Newsgroups: feec.posgrad.IA368F
Marcos Lordello Chaim escreveu:
> Acredito que as secoes "Funcionalidade" e "Arquitetura" devem definir
> as funcionalidades e a arquitetura (um ou mais servidores,
> base de dados centralizada x distribuida, estrutura de dados etc.),
> utilizando alguma forma de referenciacao. As demais secoes
> simplesmente fariam referencia a elas.
>
Sobre arquitetura do sistema, eu esperava que fosse definido COMO
as funcionalidades especificadas para o sistema podem ser implementadas.
Relaciono algumas da funcionalidades e a minha visão de como
implementá-las.
Por favor, se estiver enganada, me corrijam.
1- funcionalidade "compor disciplina", onde se espera a participação de
vários autores (co-autoria), como isto pode ser feito?
Resp.: utilizando-se um sistema hipermídia que suporte trabalho
colaborativo (além de um browser e servidor WEB).
2- funcionalidade "compor disciplina": como o conteúdo da disciplina será
armazenado?
Resp. através de documentos HTML.Tambem é necessário um banco de dados
que contenha meta-informações sobre aulas, supondo que o material poderia
estar organizado por aulas e também meta-informações sobre provas.
3- funcionalidade "estabelecer perfis para cada curso e diferentes níveis
de acesso", como oferecer isto?
Resp. banco de dados (acho que tem que ser centralizado) que armazena
informações sobre os documentos HTML que compõem a disciplina, por exemplo:
para o curso eng. eletrica, os documentos HTML são A, B, C e D e para eng.
química são A, B, E e F.
4- funcionalidade "cadastrar atores com diferentes perfis e níveis de
acesso": como isto será implementado?
Resp. utilizando-se um banco de dados distribuído, pois cada curso
teria somente os dados dos seus alunos que estão cursando a disciplina.
5- funcionalidade"disponibilizar a disciplina/aulas": como oferecer isto?
Resp.: supondo que a participação dos atores é remota e assíncrona, ou
seja, ao se inscrever no curso, o aluno é informado do prazo de duração do
curso; ele pode "assistir/participar" de uma aula no horário que melhor lhe
convier e as partes que lhe interessar. Neste contexto, tem-se 3 situações:
interação do aluno com a aula, interação do aluno com o instrutor, e
interação do instrutor com um grupo de alunos.
Interação aluno-aula: através de um sistema hipermídia (hipertexto,
hiperlinks, recursos multimídia, etc.) que possua recursos para armazenar:
anotação do aluno sobre um determinado tópico da aula num banco de dados; a
aula corrente que o aluno está participando; as aulas que o aluno já
assistiu (histórico); etc..
Interação aluno-instrutor: para registrar e esclarecer dúvidas é preciso um
banco de dados e um mecanismo que avise ao instrutor a existência de dúvida
para ser esclarecida e ao aluno o esclarecimento de uma dúvida que ele
registrou. Este mecanismo pode ser um correio eletrônico.
Interação entre instrutor-grupo de alunos: pode-se supor que
quando vários alunos têm dúvidas sobre um mesmo assunto o instrutor pode
agendar reuniões "virtuais" e realizá-las através de chats.
6- funcionalidade "acompanhar o andamento da disciplina": como fazer isto?
Resp: instrutor pode consultar o histórico dos alunos, para isto
precisa do banco de dados .
7- funcionalidade "aplicar provas": como a prova faz parte do material, ela
estaria no banco de dados de meta-informações sobre prova. Supondo que a
prova deve ser aplicada com tempo de duração pré-definido, como controlar
isto?
Resp.: não sei.
8- funcionalidade "aplicar provas": como e quando a prova será aplicada ao
aluno?
Resp. Supondo que a solicitação da prova é feita de alguma forma (a
definir) para o sistema e que a prova, independente de seu tipo (teste ou
dissertativa), é apresentada para o aluno, ele terá o tempo x para
responder. Portanto, é necessário um banco de dados para armazenar a prova
(banco centralizado) e a resposta da prova (banco de dados distribuído),
pois cada resposta de prova é referente a um aluno.
Adriana
Subject: Re: Relatorio Final Formato de Documentos na Web - Comentarios
Date: Wed, 15 Apr 1998 16:57:35 -0300
From: Raquel Santos Schulze
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
Ola, Chaim,
Quanto a questao que voce coloca sobre agentes inteligentes, participei
do grupo F3, Formatos de dados na Web, onde trabalhamos a questao de
agentes inteligentes. La, fornecemos bibliografia. Espero que ajude de
alguma forma.
Ate a proxima,
Raquel
Subject: XML Ad Hoc Group (fwd)
Date: Thu, 16 Apr 1998 17:19:48 -0300
From: "Ivan L. M. Ricarte"
Organization: Universidade Estadual de Caspinas
Newsgroups: feec.posgrad.IA368F
*** Announcing ***
IEEE Learning Technology Standards Committee
Ad Hoc Group on XML
XML, the eXtensible Markup Language, is a subset of ISO standard SGML
developed by the W3C for efficient use on the Web. While still an emerging
technology, XML has captured the imagination of the high tech industry.
Pundits foresee qualitatively improved Web applications that rely upon XML
as a common format to represent structured data of all sorts. Several
vendors have announced XML related products, including both Microsoft and
Netscape who plan significant browser support.
XML will likely become important in learning applications. I would like to
start a discussion group to explore XML's relevance to LTSC
standardization activities. It will begin as an informal ad hoc group with
a discussion list. It will not be a formal entity within LTSC, which at
present can only charter working and study groups for specific
standardization problems. If sufficient interest develops in formalizing
this discussion we can investigate what it takes to set up a parallel 'IEEE
Technical Committee' to LTSC.
XML can potentially be used in many ways in learning applications. To
attempt a tractable problem, I suggest that we focus on XML's relevance to
specific LTSC working groups rather than considering its educational uses
generally. I see two primary objectives for this discussion. The first is
to clarify what XML technologies can and cannot do with respect to LTSC
requirements. The second is to promote harmonization between LTSC
standards by using a hypothetical, XML common denominator to identify
plausible convergence points.
The LTSC working groups where I see greatest relevance are:
P1484.6 Course Sequencing;
P1484.10 CBT Interchange Language;
P1484.11 Computer Managed Instruction;
P1484.12 Learning Objects and Metadata.
I suggest that we initially focus on these four standardization
activities.
The XML technologies I would like to evaluate are of two sorts. First,
there are those related to the core XML architecture, broadly
construed. Examples include the XML link language (XLL), the XML style
language (XSL), the CSS style language, the Document Object Model (DOM) and
ECMAScript. Second, there are relevant special purpose languages that will
be represented in XML. Examples include the Resource Description Framework
(RDF) and the Synchronized Media Integration Language (SMIL), both from the
W3C. I suggest the following method. Imagine a selected set of LTSC
standardization activities as completed applications. Assume that these
applications harmonize with each other and are integrated by XML in some
way. Explore how various XML technologies might satisfy both application
and integration requirements.
A few caveats. All LTSC standardization activities are in the early
stages. Imagining an activity as a hypothetical application entails a
conceptual leap that may diverge significantly from the eventual
standard. At present, I am not aware of any LTSC working group that has
made a formal commitment to using XML. Such commitments cannot be
assumed. There are existing lists that discus XML from the perspectives of
its SGML heritage and implementation concerns. I hope to avoid detailed
discussion on these topics.
The preceding suggestions are mainly to get us started. What LTSC-XML
ultimately becomes will depend on what people want to do. As our first
action item, I strongly suggest that we write a mission statement that
clarifies what we are about.
To subscribe to the discussion list, send the message:
subscribe LTSC-XML <FirstName> <LastName>
to the address: listserv@listserv.readadpc.com.
Thank you,
Tyde Richards
Manager, Open Standards Development
Interactive Learning Division
Macromedia
E-mail: trichards@macromedia.com
voice: (760) 728-9345
Subject: Adendo: XML Ad Hoc Group (fwd)
Date: Fri, 17 Apr 1998 08:39:21 -0300
From: "Ivan L. M. Ricarte"
Organization: Universidade Estadual de Caspinas
Newsgroups: feec.posgrad.IA368F
From: Tyde Richards
Subject: LTSC-XML Error
For those wishing to subscribe to the LTSC-XML list, the subscription
information in the annoucement contained a typo. The correct information
is:
send the message: subscribe LTSC-XML <FirstName> <LastName> to the
address: listserv@listserv.readadp.com.
Apologies. Please provide the correct information if you forward the
announcement.
Thanks,
Tyde
ricarte@dca.fee.unicamp.br
Last modified: Thu Apr 23 10:49:47 BRA 1998