Skip to topic | Skip to bottom
Home

TechWeb12
TechWeb12.Segnalazioni1112r1.27 - 13 Jan 2012 - 14:29 - OctavianBujortopic end

Start of topic | Skip to actions

Errori

In questa sezione saranno segnalati gli errori trovati nel protocollo. Sara' presa visione (idealmente) di ogni errore. Ad ogni errore sara' assegnato uno status: Visionato, Corretto, CRITICO. L'ultimo status e' riservato a quegli errori che, per essere corretti, richiedono pesanti modifiche alle specifiche del protocollo. L'inserimento dello status e' a carico del WG. Se chi inserisce l'errore e' convinto che debba essere preso in considerazione al piu' presto e' pregato di contattare ALMENO un membro del WG. Ogni errore DEVE essere corredato dalla firma del submitter.

Syntax:

Errore $NUM

Descrizione: [...]

Status: [...]

--$FIRMA_DEL_SUBMITTER

Proposte e Commenti

Le discussioni (botta e risposta) devono avvenire ESCLUSIVAMENTE su IRC e simili. Sara' presa visione del numero massimo possibile di proposte inviate dal WG. Gli status possibili delle proposte saranno: Visionata, Accettata, Rifiutata.

Syntax:

Proposta $NUM

Descrizione: [...]

Status: [...]

--$FIRMA_DEL_SUBMITTER

-- MarcoChiappetta - 23 Nov 2011

  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE =

Proposta 01

Descrizione: sarebbe interessante avere la possibilità di lasciare un commento all'interno del database,
ma attualmente non è possibile farlo a causa della mancanza di un tag appropriato
propongo la possibilità di farlo aggiungendo la parola chiave note magari nella sezione dei metadati
-- GiulioBiagini - 22 Dec 2011

Proposta 02

Descrizione: nella parte relativa all'esempio json, nel paragrafo 6 del nuovo protocollo 0.9.2 c'è: "tel": "051 236113",
dove "tel" non è una parola chiave definita, credo sia da cancellare
inoltre c'è: "address": "Via Farini, 30 - Bologna BO"
credo sarebbe meglio uniformare la sintassi come negli altri formati: "address": "Via Farini, 30, cap, Bologna, Italy"
-- GiulioBiagini - 22 Dec 2011

Proposta 03

Descrizione: sarebbe interessante poter aggiungere una parola chiave NCONTAINS, la quale specificherebbe un comportamento contrario a CONTAINS, come parametro dell'aggregatore
attualmente risulta infatti molto difficoltoso avere ad esempio l'elenco delle farmacie chiuse di sabato
bisogna fare un "CONTAINS Sat" cioè tutte quelle aperte di sabato e toglierlo dall'elenco di tutte le farmacie (operazione complessa e non banale)
grazie a NCONTAINS operazioni come questa risulterebbero decisamente più semplici ("NCONTAINS Sat")

Status: Accettata -- GiulioBiagini - 30 Dec 2011

Proposta 04

Descrizione: Nel protocollo, esattamente nel formato delle date, vengono specificati alcuni esempi di date nel formato gg/mm/aaaa.
Dovremmo tuttavia adottare il formato dei file sorgenti del Prof, ossia mm/gg/aaaa in modo da uniformare la sintassi a un singolo modello.

Status: Accettata (con modifica) -- RiccardoFalco - 02 Jan 2012

Proposta 05

Descrizione: propongo di avere un formato unico per gli orari e le date sia nei database sia per le richieste all'aggregatore
così per la ricerca sarà sufficiente un semplice CONTAINS tra il valore passato all'aggregatore e il valore nel database, in quanto avranno lo stesso formato
e non bisognerà trasformare la data dal formato "gg-mm-aaaa" in ingresso all'aggregatore al formato "gg/mm/aaaa" mantenuto nei database
l'implementazione risulterebbe così molto più comoda ed efficiente
in particolare proponevo un formato tipo "gg-mm-aaaa" per l'anno (in quanto i "/" sono usati per separare i dati in input all'aggregatore)
mentre per l'orario il formato che c'è già "hhmm" andrebbe bene, oppure uniformare con un formato simile a quello delle date "hh-mm"
anche in questo caso uno stesso formato sia per gli orari in ingresso all'aggregatore sia per gli orari nel database
comunque il problema non è tanto il formato in sè, quanto più avere coerenza tra il formato in input all'aggregatore e quello mantenuto nel database appunto

Status: Rifiutata (richiesta identica alla 4) -- GiulioBiagini - 02 Jan 2012

Proposta 06

Descrizione: propongo di inserire il confronto NCONTAINS ovunque sia presente il suo opposto CONTAINS
in particolare anche per gli id e gli address
es: tutte le farmacie che non sono a bologna: address NCONTAINS Bologna
che mi sembra una richiesta all'aggregatore più che ragionevole
-- GiulioBiagini - 04 Jan 2012

Status: Accettata (con modifica)

Proposta 07

Descrizione: Mi è stato detto di controllare gli errori HTTP 403 e 501.
403: Si dovrebbe specificare quando usarlo, magari con degli esempi (ho trovato parecchi dubbi a riguardo). Penso che vada usato quando uno esterno cerca di accedere a delle directory private del gruppo (e.s. dati sensibili).
501: Non è "servizio non fornito", ma "metodo non implementato" nel protocollo HTTP. Inoltre dovrebbe essere implementato direttamente in Apache e non nei nostri script.
-- LucaRinaldi - 06 Jan 2012

Proposta 08

Descrizione: propongo nel csv di racchiudere ogni campo tra doppi apici " e non solo nei campi che richiedono la non interpretazione della virgola,
e di eliminare gli spazi tra le virgole, o almeno regolarli nel protocollo, in modo da rendere tale formato più facilmente parserizzabile,
in quanto non esistono funzioni già definite nel linguaggio che parsino automaticamente il csv (almeno non nell'attuale versione del php installata)
esempio: "cup0001","CUP","Ospedale Bellaria","Via Altura, 3, 40139, Bologna, Italy","44.464765","11.394804",ecc...
-- GiulioBiagini - 10 Jan 2012

Proposta 09

Descrizione: propongo di aggiungere nel catalogo per gli aggregatori l'attributo categories. Faccio subito un esempio per far capire l'utilità.
Adesso è strutturato così:

id="ltw1130-farmacie-supermercati" title="Farmacie e Supermercati di Bologna" url="http://ltw1130.web.cs.unibo.it/farmacie-supermercati/"

L'attributo title, è fatto per essere letto dagli umani.
Un descrittore invece dal mio punto di vista avrebbe bisogno di un altro attributo, perché come nell'esempio dei supermercati il file in json, la categoria dei supermercati è: Supermarket.
Quindi la mia proposta è di mettere l'attributo categories fatto così "categoria1,categoria2,categoria3....", dove le categorie siano quelle "vere".
Esempio con il file dei supermercati categories="Supermarket".
Per evitare una richiesta GET in più all'aggregatore, se non cè la categoria che mi interessa nel rispettivo attributo non faccio richiesta.
Il problema forse è più rilevante quando un gruppo per esempio chiama il suo aggregatore "ltwxxx-posti_bologna", e nel titolo ci mette "I posti più belli di Bologna".
In questo caso un descrittore non può capire che categorie contiene senza farne la richiesta.

-- OctavianBujor - 13 Jan 2012
to top


You are here: TechWeb12 > BestEffort1112 > Segnalazioni1112

to top

Copyright © Fabio Vitali 2017 Last update of Segnalazioni1112 on 13 Jan 2012 - 14:29 by OctavianBujor