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. |
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 |
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. |
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. |
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. |