TechWeb06
Start of topic | Skip to actions
Working Group AC-DS
Membri
Chair: JacK (42)
- E-mail:
- UIN (ICQ#): 49267297
Riunioni
Riunione.next()
Si è deciso di riunirsi in data TRILLIAN alle BEEBLEBROX presso MARVIN . In base a quanti saremo e cosa dovremo discutere, decideremo se restare li' o mettersi in fila per e^(Pi*i)+3, prendersi per mano e come una brava scolaresca andare in giro a cercare un posto
.
Verbale riunione del 26/05/2006
Decisioni prese:
-- JacK - 26 May 2006
- E' stata definita esattamente la forma degli URL che devono comparire nei cataloghi: entrambi devono fare riferimento ad uno stesso script (PHP, ASP, o quel che vi pare). Le stringhe devono avere concatenato alla fine "?req=elenco" e "?req=scheda" rispettivamente per l'URL dell'elenco e quello della "scheda".
- Sono stati eliminati gli attributi "descrizione" e "href" da tutti gli elementi presenti in "scheda".
- E' stato elminato l'elemento "extra" in "scheda".
- L'attributo "href" associato agli elementi presenti in "testo" ha assunto il nome di "urlFonte".
| Gruppo | Numero | Proposta | Commenti |
|---|---|---|---|
| DrillTeam | 01 | Stabilire in modo preciso le modalità di richiesta di una scheda tramite il suo id. | Risolto, si veda il nuovo protocollo. |
Verbale riunione del 23/05/2006
Di seguito e' riportato quanto risultato dalla discussione sulle varie proposte:
-- JacK - 23 May 2006
| Gruppo | Numero | Proposta | Commenti |
|---|---|---|---|
| DrillTeam | 1 | Problemi del Content model misto, parte 1 All'interno di elementi blocco già definiti in xhtml, come p, non è consentito inserire i nostri tag (come autore o titolo). | Risolto |
| DrillTeam | 2 | Problemi del Content model misto, parte 2 Questo è un problema molto più importante. Al momento è possibile scrivere un tag (obbligatorio o no) sia direttamente in dati sia all'interno di uno dei blocchi di testo. Sembra però che al DF faccia dispiacere avere lo stesso campo con dei valori differenti all'interno della scheda. Per fare un esempio, se sto parlando che so, di un libro di autoreDavid Eddings/autore e nel commento faccio un paragone con autore J.R.R. Tolkien/autore la cosa dovrebbe essere più che legittima, però da quanto mi è stato riferito il DF questa cosa non la apprezza. Bisogna definire questo punto | Non c'era il problema |
Verbale riunione del 17/05/2006
Premessa: gradirei sapere esattamente quali sono i gruppi attivi di questo progetto che hanno intenzione di lavorare seriamente al fine di presentare il progetto al primo appello utile. Detto in soldoni:
Inoltre, è stato deciso di eliminare l'elemento "URI" presente all'interno dell'elemento "info" di "scheda".
Per quanto riguarda le varie modifiche al protocollo, queste verranno rese disponibili nella prossima versione del protocollo stesso, che verrà redatta il prima possibile e si rifletteranno sugli schemi di validazione in Relax NG + Schematron che aggiornerò; pertanto, controllate sempre le date di ultima versione di tali schemi!
Nel correggere gli schemi di validazione, mi sono accorto che si presenta un problema legato agli elementi non ripetibili, in quanto, ora, possono essere presenti vel in "info" tolto "testo" vel in "testo". Quello che si vuole ottenere, invece, è un aut aut, cosa che penso di possa fare solo con Schematron, ci pensero'.
-- JacK - 18 May 2006
- 1) compilate la tabella dei gruppi presente in questa pagina senza inserire doppioni (ne ho gia' cancellati due) e indicando un rappresentante; le riunioni sono aperte a tutti, ma vorrei comunque avere un "entry point" (per dirlo azzardando un termine informatico) per ogni gruppo onde evitare di dover mandare eventuali e-mail a tutti i partecipanti di un gruppo;
- 2) presentatevi alle riunioni (oggi mancavano almeno 6 gruppi su 20, cioè circa 1/3 del totale) e/o fatevi conoscere in un qualche modo; questo perché non venendo non potete partecipare alle discussioni e votare a favore dell'una o dell'altra proposta e, cosa peggiore, rischiate di non ottenere una fiducia tale da poter vendere i vostri prodotti alla fiera.
| Gruppo | Numero | Proposta | Commenti |
|---|---|---|---|
| L'importante e' che salsa | 1 | Ripensando a quanto discusso nell'ultima riunione siamo fermamente convinti che gli unici campi obbligatori sono ID e Titolo ( anche se perfino su titolo ci sarebbe da discutere...).Cosa si intende per anno? Anno di pubblicazione in italia, anno di pubblicazione nel mondo, anno di una specifica edizione, anno in cui e' stato scritto, etc...???????? Anche per autore il problema persiste in quanto l'autore potrebbe essere sconosciuto o anonimo ( basta pensare a Luther Blissett ...), oppure ci potrebbero essere piu autori di cui non si sa qual'e' il reale.Ci sono poi anche casi particolari ( bibbia, corano, etc...) dove sarebbe sbagliato considerarli di autori vari( in alcune biblioteche ad esempio sono sotto la voce D) e quindi anche in questo caso non ci sarebbe uniformita'.Detto cio' esortiamo di riconsiderare la proposta da noi presentata nell'ultima riunione del working-group. | NO. |
| 42 | 2 | Visto che i risultati per le query "titololibro" e "libroautore" sono, rispettivamente, gli stessi che si ottengono per "titolo" e "autore" sarebbe sufficiente dire che tutti i DS devono gestire obbligatorimanete "titolo" e "autore". | OK. |
| 42 | 3 | Per quanto riguarda l'utilizzo delle wildcard e affini si propone la seguente interpretazione, dove a sinistra dell'implicazone vi è la stringa usata nel form di query, mentre a destra la ricerca effettiva che verrebbe eseguita:
| Si è deciso che tutti i gruppi devono gestire obbligatoriamente la ricerca in questo modo: se viene specificata una stringa, questa deve essere ricercata come sottostringa dell'elemento voluto (è il caso di Ada => |
| 42 | 4 | Bisogna decidere quali elementi di xhtml permettere all'interno delle schede. Se date un occhio agli schemi di validazione in Relax NG vedrete che di tutti i moduli di xhtml ne ho rimossi una buona parte, lasciando solo quelli che pensavo potessero servire. Tuttavia immagino che vi siano ancora vari elementi da escludere. Per ora dentro un elemento contenuto dentro a "testo" si possono inserire, oltre ai "nostri" elementi: a, abbr, acronym, address, blockquote, br, button, cite, code, del, dfn, div, dl, em, fieldset, form, h*, img, input, ins, kbd, label, li, noscript, ol, p, pre, q, samp, script, select, span, strong, table, textarea, ul, var. | Dall'elenco di tag "difianchdetto" sono stati eliminati button, div, fieldset, form, img, input, label, noscript, script, select, span, textarea. |
| DrillTeam | 5 | Numero di elementi voce in un elenco Al momento elenco è teoricamente composto da uno o + elementi voce. Tuttavia, siccome una ricerca può benissimo ritornare 0 risultati, bisogna ammettere che possa ritornarne anche zero, o, in alternativa, consentire un tipo di errore che specifichi "ricerca senza risultati". Fra parentesi, bisognerà anche fare un rapido schema RNG per l'elenco. | OK. |
| DrillTeam | 6 | N° di elementi in una query di ricerca Sarebbe molto comodo che nella query si potessero specificare due parametri addizionali: numero di elementi che si vuole visualizzare per pagina e numero di pagina da visualizzare. Se fate caso, in quasi tutti i portali c'è un meccanisimo di visualizzazione dei risultati delle ricerche di questo tipo. Anche per facilitare la vita ai formatter e per avere layout più leggibili, perchè si rischia di avere delle query (specie grazie alle wildcard) che restituiscono centinaia di risultati nell'elenco! | Sara' ciascun application controller a gestire in modo opportuno tale problema, quindi non è una decisione da prendere in comune. |
| DrillTeam | 7 | Campi obbligatori nelle ricerche e nelle schede Ci sarebbe l'esigenza di arrivare ad una posizione finalmente ufficiale su questi discorsi, visto che le ultima volta la discussione si era conclusa in un nulla di fatto. Chiediamo perciò una votazione ufficiale in modo da avere delle decisioni ufficializzate. La nostra proposta è questa: Solamente autore e titolo come campi obbligatori nelle ricerche, visto che quasi nessun sito che offra servizi per i data intermediary consente di effettuare ricerche in base all'anno di pubblicazione (ed oltretutto è una ricerca di scarso significato) Campi obbligatori in ogni scheda autore e titolo, senza i quali di fatto non si ha nemmeno l'identificativo minimale di un libro. Inoltre c'è molta differenza fra mancanza d'informazione totale, o un informazione che dice che un dato campo non è disponibile. Un data source di tipo data intermediary può tranquillamente copiare nel campo autore quanto viene restituito dal sito su cui si appoggia (nel caso di amazon, il campo dietro la tilde può contenere), e se non ha informazioni, può aggiungere automaticamente una stringa specifica. E dire che se un vecchietto vede scritto "autore: dato non disponibile" (o simili) poi non riesce a trovare il libro su amazon non mi sembra una motivazione sensata! | OK! Finalmente si è concluso che i campi di ricerca obbligatori nei form e gli elementi obbligatori nelle schede sono AUTORE e TITOLO!!! |
| DrillTeam | 8 | Modifiche minori ad alcuni content model nella scheda Principalmente, la richiesta è quella di consentire ciclo come elemento ripetibile, semplicemente perchè spesso un libro viene identificato come parte di più cicli, o magari è parte di un sottociclo all'interno di un ciclo stesso. Inoltre, potrebbero esserci altre proposte per aggiustamenti minori. | OK. |
Verbale riunione del 08/05/2006
Di seguito e' riportato quanto risultato dalla discussione sulle varie proposte:
-- JacK - 02 May 2006
| Gruppo | Numero | Proposta | Commenti |
|---|---|---|---|
| L'importante e' che salsa | 1 | Stabilirte un ID univoco per un libro questo per la richiesta della scheda. Una alternativa potrebbe essere quella di concatenare le informazioni numeroGruppo.numeroDataSource.idLibroIl numeroGruppo si puo' assegnare in base all'ordine di iscrizione al progetto. Es. Ho i seguenti gruppi: 1) Pippo 2) Pluto 3) Minni il seguente id 2.4.12346 rappresentera' un libro di id 12346 situato nel datasource numero 4 del gruppo 2 (Pluto). | Respinta. |
| L'importante e' che salsa | 2 | DTD keyword: Aggiungere come anni passati elemento voce all'interno del DTD questo per creare un range di scelte Es. se vuoi ricercare tutti i libri con il titolo pippo in forma multimediale la query sara= ?titolo=pippo&supporto=multimediale(ad esempio) Ora come sappiamo che la ricerca deve essere fatta con il valore multimediale e non multimedia o multi, aggiungendo all'interno del DTD di keyword un elemento voce contenente multimediale risolviamo il problema:
| Respinta. |
| 42 | 3 | La soluzione migliore al "problema" dell'elemento "autore" mi pare essere la seguente (codice RelaxNG sul ng): <autore>Nome Cognome</autore> | Accolta. |
| 42 | 4 | Ho rilasciato una prima versione dei fogli di validazione in RelaxNG+Schematron nella parte appropriata di questa pagina. Rimando al post sul ng per chiarimenti. | In progress. |
Verbale riunione del 02/05/2006
Di seguito e' riportato quanto risultato dalla discussione sulle varie proposte:
-- JacK - 02 Mag 2006
| Gruppo | Numero | Proposta | Commenti |
|---|---|---|---|
| 42 | 1 | Bisogna permettere di poter registrare più data source e più data formatter all'interno di uno stesso catalogo; la registrazione di un catalogo per ogni data source ci sembra poco opportuna. Si propone semplicemente di creare un elemento contenitore "cataloghi", che diventerebbe la nuova radice dell'xml che rappresenta un catalogo. | La modalità per aggiungere più DS o più DF consiste nel registrare più entry nelle rispettive pagine di registrazione. |
| 42 | 2 | Poiché l'anno di prima pubblicazione di un libro (elemento obbligatorio) pare non essere reperibile in modo automatico per data source intermediary, in particolare da Amazon, si propone di utilizzare l'elemento "anno" per indicare l'anno "corrente" di pubblicazione di un libro, mentre destinare l'anno di prima pubblicazione al nuovo elemento "annoPrimaPubblicazione", il quale può essere facilmente gestito con data source storage ed è naturalmente opzionale. | Sono stati aggiunti gli elementi anno e annoPrimaPubblicazione. |
| DrillTeam | 3 | Per alcuni elementi il content model appare nettamente sbagliato. Ad esempio l'elemento descrizione nella parte globale (cfr cap 4) è %inline, quando dovrebbe essere %CMinline. Così via per altri elementi simili | Ci sono molti errori che verranno corretti nella stesura dei fogli di validazione. Per ora ci si affida al buon senso nel creare le schede. |
| DrillTeam | 4 | Richiesta di separare gli elementi dei metadati informativi dagli altri elementi atomici (quelli dei dati veri e propri), per una migliore gestione sia a livello logico, sia a livello di validazione nonchè a livello implementativo. Per metadati informativi intendo quel gruppetto di elementi atomici come id, autoreScheda, team, origine, URI, creatoIl, modificatoIl. | Durante la riunione si è detto che non c'e' nessun problema a lasciar tutto così, ma a posteriori (=dopo la riunione) mi è stato fatto notare che così si possono inserire tutti gli elementi presenti nel content model dell'elemento "info" (cioe' %atomici;) anche dentro a "dati", cosa che non ha molto senso. Se non avete nulla in contrario li elmino dall'elenco degli elementi presenti nell'entità parametrica "atomici". |
| DrillTeam | 5 | Richiesta di usare Relax NG come linguaggio di validazione per le versioni future del protocollo | Si è scelto di utilizzare RelaxNG in combinazione con Schematron. |
| DrillTeam | 6 | Varie ed Eventuali (Richiesta di inserimento di specifiche opzionali o estensioni da parte dei gruppi; Dibattito su alcune modifiche che sono state apportate senza essere discusse) | Fatto. Tutte le modifiche/aggiunte sono preenti nella pagina del protocollo. |
| 42 | 7 | Perché non partiamo da una versione in Relax NG di XHTML 1.0 Strict (http://www.w3.org/People/mimasa/test/schemas/rng/xhtml1-strict.rng) e la modifichiamo per i nostri scopi? Oltre a non dover ridefinire tutte le potenzialità di XHTML 1.0 Strict, otterre(m)mo incidentalmente una versione di XHTML 1.0 Strict con co-constraint definiti con Schematron, di cui ora pare essere priva. A questo punto il nostro lavoro si limiterebbe a definire i content model caratteristici del nostro protocollo, ovviamente non presenti in XHTML, quali catalogo_datasource, catalogo_formatter, ecc. e a trovare una corrispondenza tra quegli elementi che sono implicitamente equivalenti ad elementi XHTML: ad esempio, "contenuto" e "recensione" possiamo semplicemente definirli con la stessa sintassi con cui è definito l'elemento "div". | Ancora da decidere da che parte iniziare. Si è proposto di partire piuttosto da XHTML 1.1, poiché non dovrebbe contenere elementi presentazionali e dovrebbe essere struttuturato modularmente. |
| 42 | 8 | Immagino lo stiate pensando un po' tutti: è necessario stabilire un ID univoco da associare a ciascuna scheda in modo che che sia identificata univocamente tra i vari DS che ciascun gruppo si ritroverà ad avere dopo la fiera o trovare un altro meccanismo per stabilire senza ambiguità a quale DS appartiene una certa scheda. | L'utilizzo di un ID che sia univoco solamente all'interno di un singolo DS potrebbe non essere sufficiente, da valutare l'estensione dell'univocità dell'ID a tutti i DS prodotti da un gruppo. |
| UnVenerdìDaRane | 9 | Content Model misto per le schede: i DTD/RNG dovrebbero essere adattati per permettere ai DS di utilizzare indistintamente delle schede con CM "a mo' di record" e delle schede con Content Model misto. Il CM misto permette di scrivere delle schede "più semantiche", in cui le informazioni rimangono nel loro contesto originale e vengono taggate per aggiungere metainformazioni. Inoltre gli XPath che funzionano con il CM misto funzionano anche con il CM a record. La pagina con gli esempi ed il resto della proposta è PropostaDS-CM_Misto. | Si è scelto di rendere possibile l'utilizzo di entrambi i modelli. |
Verbale riunione del 26/04/2006
Breve riassunto della riunione:
- descrizione generale, a grandi linee, del funzionamento di tutto il progetto;
- lettura di tutto il protocollo, sia per il DS sia per il DF, per una prima scrematura degli errori più evidenti;
- decisione di pubblicare entro un paio di giorni un catalogo per il DS e per il DF nelle apposite pagine, in modo da poter iniziare ad implementare gli script necessari a realizzare il progetto.
Verbale riunione del 19/04/2006
Tecnicamente non è stata una riunione di questo working group poiché quest'ultimo non è ancora ben definito :).
In pratica sono stati eletti i chair per i due working group ed è stato discusso a grandi linee di come trattare il problema Ajax. Poiché la maggior parte dei presenti non aveva letto ancora approfonditamente le specifiche si è ritenuto opportuno rimandare alla prossima riunione ulteriori considerazioni sul protocollo.
Compito per casa: leggere le specifiche iniziali del protocollo versione 0.9! :P
-- JacK - 19 Apr 2006
Versioni del protocollo
Versione AC-DS 5 del 26/05/2006
Versione AC-DS 4 del 17/05/2006
Versione AC-DS 3 del 08/05/2006
Versione AC-DS 2 del 02/05/2006
Versione AC-DS 1 del 27/04/2006
Versione 0.9.01 del 26/04/2006
La pagina contenente la versione del protocollo 0.9.01 (nella quale vi è già un buon numero di correzioni sintattiche e semantiche, proposte, ecc.) sarà resa leggibile dopo la riunione del 26/04/2006, nella quale verrà discussa, appunto, la versione iniziale del protocollo. Questo per invogliarvi a cercare tutti i possibili errori senza influenzarvi (sento dei coltelli avvicinarsi alle mie spalle 
).
-- JacK - 19 Apr 2006
Rendo disponibile in lettura tale pagina a partire da...ORA!
-- JacK - 26 Apr 2006
).
-- JacK - 19 Apr 2006
Rendo disponibile in lettura tale pagina a partire da...ORA!
-- JacK - 26 Apr 2006
Documenti di validazione RelaxNG+Schematron
In questa sezione verranno distribuiti i documenti di validazione per le parti inerenti al protocollo del DS.
Per giocare con XML e con gli schemi di validazione vi consiglio vivamente di utilizzare oXygen (http://www.oxygenxml.com/).
Per vedere cosa puo' contenere un certo elemento la cosa più comoda è:
- inserire all'inizio del documento (dopo <?xml ... ?>) <?oxygen RNGSchema="file:/$path" type="xml"?>, dove $path è il percorso del file "scheda.rng";
- posizionarsi all'interno dell'elemento di cui si vogliono sapere i possibili contenuti scrivere un "<" attendendo il menu di autocompletamento.
- catalogoDataSource (ultimo aggiornamento 26/05/2006 - 22:29:31):
- catalogoRelaxNG_Schematron.rar
- catalogoRelaxNG_Schematron.tar.gz
- catalogoRelaxNG_Schematron.tar.bz2
- Una panoramica sui file presenti nei pacchetti relativi a "catalogoDataSource":
- catalogoDS.xpr = file progetto di oXygen;
- catalogoDataSource.xml = un esempio di catalogoDataSource validato;
- catalogoDataSource.rng = file principale che definisce gli elementi del catalogo e contiene i moduli utilizzati per validare un catalogoDataSource. E' quello da utilizzare per la validazione!
- modules/ = directory contentente alcuni moduli di XHTML 1.1.
- scheda (ultimo aggiornamento 26/05/2006 - 22:04:21):
- schedaRelaxNG_Schematron.rar
- schedaRelaxNG_Schematron.tar.gz
- schedaRelaxNG_Schematron.tar.bz2
- Una panoramica sui file presenti nei pacchetti relativi a "scheda":
- scheda.xpr = file progetto di oXygen (in pratica mostra nel riquadro "Project" i soli moduli utilizzati veramente);
- scheda.xml = un esempio di scheda validata;
- scheda.rng = file principale che contiene tutti i moduli utilizzati per validare una scheda. E' quello da utilizzare per la validazione!
- xhtml* = file che includono i moduli per 3 versioni differenti di xhtml (lasciati per curiosita', non servono);
- modules/ = directory contentente tutti i moduli di XHTML 1.1 (anche quelli non utilizzati) piu' il seguente file;
- modules/structScheda.rng = file che definisce tutti gli elementi che compongono una scheda, non gia' presenti in XHTML 1.1.
- Un paio di file che possono esservi di aiuto se volete convertire in modo veloce le schede; in particolare la versione del foglio xslt distribuita serve ad adattare il contenuto di "testo" secondo le nuove specifiche:
- elenco (ultimo aggiornamento 26/05/2006 - 22:52:21):
- elencoRelaxNG_Schematron.rar
- elencoRelaxNG_Schematron.tar.gz
- elencoRelaxNG_Schematron.tar.bz2
- Una panoramica sui file presenti nei pacchetti relativi a "scheda":
- elenco.xpr = file progetto di oXygen (in pratica mostra nel riquadro "Project" i soli moduli utilizzati veramente);
- elenco.xml = un esempio di elenco validato;
- elenco.rng = file principale che contiene tutti i moduli utilizzati per validare un elenco. E' quello da utilizzare per la validazione!
- xhtml* = file che includono i moduli per 3 versioni differenti di xhtml (lasciati per curiosita', non servono);
- modules/ = directory contentente tutti i moduli di XHTML 1.1 (anche quelli non utilizzati) piu' il seguente file;
- modules/structElenco.rng = file che definisce tutti gli elementi che compongono un elenco, non gia' presenti in XHTML 1.1.
Registrazione cataloghi DS
La registrazione dei cataloghi dei DS deve avvenire nell'apposita pagina, secondo le modalità indicate nella stessa.
- Set ALLOWTOPICVIEW =
- Set ALLOWTOPICCHANGE =
- Set DENYTOPICCHANGE = AndreVitali?
- Set ALLOWTOPICRENAME = JacK
- Set IMMEDIATENOTIFY = AntonioLaccetti
to top
Edit | Attach image or document | Printable version | Raw text | More topic actions
Revisions: | r1.329 | > | r1.328 | > | r1.327 | Total page history | Backlinks
Revisions: | r1.329 | > | r1.328 | > | r1.327 | Total page history | Backlinks