Protocollo AC-DS

Versione 3 – 08/05/2006

Autore: JacK (Working Group DS)

È disponibile una versione pdf delle specifiche (compressa tar.bz2) che riduce il numero delle pagine da stampare mantenendo alta la leggibilità. Scarica

In fondo alla pagina, nell'apposita sezione, viene generato automaticamente il riassunto delle modifiche apportate al documento rispetto alla versione precedente. Pertanto, bisogna avere Javascript attivo.

0. Linee guida ASSOLUTAMENTE DA LEGGERE

• l'encoding da utilizzare per i caratteri è UTF-8;
• le date devono essere nel formato yyyymmgg (quindi, 4 cifre per l'anno, 2 per il mese e 2 per il giorno; non sono ammesse abbreviazioni come 200611 al posto di 20060101);
• i valori booleani sono espressi con le stringhe "true" e "false";
• gli URL di risorse esterne alla scheda devono essere assoluti (ad esempio, l'url di una copertina).
• i content model corretti non sono quelli presenti in questo documento, per ora fate riferimento agli schemi di validazione in RelaxNG+Schematron.

3. Query al Data Source

Come specificato in sezione 2, l’applicazione può inoltrare tre tipi di richieste al Data Source:

• catalogo ossia le metainformazioni relative al DS
• elenco ragionato sui dati presenti nel DS, costruito in base ai parametri della query specificati dall’utente.
• scheda delle informazioni associate ad un documento o di una pagina intermedia.

Nelle sottosezioni successive sono riportate le specifiche dettagliate e complete per l’inoltro delle query verso il DS.

3.1 Il catalogo

Tale richiesta è realizzata con una GET HTTP di un documento con URL stabilito e reso pubblico da ogni DS al momento della registrazione (nella sezione 8 sono riportate le regole per la registrazione dei data-source e dei formatter). Si assuma ad esempio che nel wiki sia registrato il seguente DS:

L’URL da utilizzare per la richiesta è appunto

http://tw.web.cs.unibo.it/TWds.xml

Il DS risponde con una auto-descrizione espressa in sintassi XML secondo le specifiche riportate nella sezione 4.1. Si noti che il catalogo può essere un documento statico o dinamico e che è necessario fornire anche una versione human-readable (HTML) dello stesso.

Il ruolo del catalogo di un DS è fondamentale: per ogni richiesta l'AC deve consultare il catalogo del DS e recuperare l'URL completo per richiedere un'elenco di dati o una singola scheda. Sebbene sia possibile implementare meccanismi di caching, è obbligatorio recuperare dinamicamente l'indirizzo dello script del DS dal catalogo. La modifica degli URL relativi ad un DS, quindi (tranne l'URL del catalogo) deve essere automicamente gestita dall'AC, senza nessuna modifica manuale al codice dell'applicazione.

3.2 L’elenco

Tale richiesta è realizzata con una GET HTTP all’URL specificato nel catalogo dall’elemento elenco,inserito nella parte globale. Il contenuto dell’elenco è parametrizzato: i parametri di costruzione dell’elenco vengono specificati al momento della richiesta da parte del AC attraverso una query string e devono essere fra quelli supportati dal DS. I parametri supportati dal DS sono a loro volta specificati all’interno della parte query nella descrizione del catalogo. Si rimanda alla sezione 4.1 per una descrizione dettagliata dei meccanismo di accesso e query specificati all’interno del catalogo.

L’applicazione potrebbe richiedere, ad esempio, la risorsa:

http://tw.web.cs.unibo.it/get.php?anno=1999

a cui il DS risponderà con l’elenco delle schede disponibili dell’anno 1999, in sintassi XML secondo le specifiche riportate in sez. 4.2.

3.3 La scheda

Tale richiesta è realizzata con una GET HTTP all’URL specificato nel catalogo dall’elemento scheda,inserito nella parte globale. Con questa richiesta è necessario specificare nella query string l’identificativo univoco della scheda richiesta (contenuto nell’elemento id della scheda).

Ad esempio la richiesta di una scheda potrebbe essere:

http://tw.web.cs.unibo.it/get.php?id=23

Si rimanda alla sezione 4.3 per una descrizione dettagliata dei meccanismo di accesso specificati all’interno del catalogo.

4. Output del Data Source

Il data source (o DS) è un modulo indipendente (cioè scollegato da qualunque altra applicazione) e passivo (cioè non ha comportamenti proattivi, ma risponde soltanto ad esplicita richiesta) che fornisce contenuti in formato XML

I data source possono essere data storage (cioè posseggono effettivamente i dati che sono in grado di restituire) oppure data intermediary (cioè estraggono i dati da qualche fonte su Internet e la restituiscono nel formato richiesto).

Ogni data source deve obbligatoriamente fornire tre servizi: il catalogo, l’elenco e la scheda.

4.1 Il catalogo

Il catalogo è un documento statico in cui vengono elencate le funzionalità fornite dal modulo. Attraverso il catalogo un’applicazione o un utente a valle può decidere cosa utilizzare del modulo e come. Il catalogo è sempre accessibile via un URI fisso obbligatoriamente registrato (vedi cap. 8).

<!ELEMENT catalogoDataSource   (globale, query) >

Il catalogo ha l’elemento catalogoDataSource come radice, ed è diviso in due parti: globale e query. Nella parte globale si forniscono informazioni sul modulo e i suoi percorsi di accesso ai vari tipi di output. Nella parte query si forniscono i criteri in base ai quali è possibile fare interrogazioni e ottenere elenchi.

4.1.1 La parte globale

L’elemento globale riporta il nome del DS, una descrizione leggibile del tipo di contenuti del DS, i meccanismi di accesso ai vari tipi di query. L’attributo tipo specifica se il DS è un data storage o un data intermediary. I meccanismi di accesso sono URI da utilizzare per accedere ai vari tipi di documento (catalogo, elenco e scheda)

<!ENTITY  % URI CDATA >

<!ELEMENT globale     (nome, descrizione, accesso) >
<!ATTLIST globale
          tipo        (storage|intermediary)   #REQUIRED>
<!ELEMENT nome        (#PCDATA)>
<!ELEMENT descrizione %CMinline;>
<!ELEMENT accesso     (elenco, scheda)>
<!ELEMENT elenco      %URI; >
<!ELEMENT scheda      %URI; >

Ogni URI è assoluto, e può contenere la stringa "xxx" per indicare una parte variabile. La stringa "xxx" non può appartenere all’URI per altro scopo che individuare una parte variabile. Ad esempio:

<scheda>http://www.sito.com/scheda.php?id=xxx</scheda>

Un vincolo aggiuntivo è imposto ai valori di %URI; nel caso degli elementi elenco e scheda. Entrambe le richieste devono avere lo stesso URL di base e possono differenziarsi solo nei parametri della query string. Ad esempio:

<scheda>http://www.sito.com/techweb_ds.php?req=scheda&id=XXX</scheda>

<elenco>http://www.sito.com/techweb_ds.php?req=elenco</elenco>

4.1.2 La parte query

La parte query contiene la lista delle keyword rispetto alle quali il DS permette di eseguire una query per ottenere un elenco. Di ogni keyword va specificato il nome e il tipo (stringa, intero, data o booleano). In particolare, le date andranno espresse nel formato yyyymmgg, mentre i valori booleani con le stringhe "true" e "false". Su tutte le keyword è ammessa la ricerca per wildcard (cioè senza un valore esplicito).

<!ELEMENT query (keyword+) >
<!ELEMENT keyword     EMPTY >
<!ATTLIST keyword
          nome  CDATA #REQUIRED
          descrizione CDATA #IMPLIED
          tipo  (stringa | intero | data | booleano)  "stringa"
          >

Ad esempio la seguente dichiarazione esprime una keyword di tipo intero:

<keyword nome="anno" descrizione="Anno di pubblicazione di un libro" tipo="intero"/>

4.2 L’elenco

L’elenco è un documento generato come risposta ad una query. La query è sempre una espressione della forma campo1=val1&campo2=val2… in cui campo1 e campo2 sono keyword ammesse alla query, e val1 e val2 sono valori compatibili con i tipi dei campi 1 e 2.

Esistono le keyword predefinite annolibro, libroautore e titololibro per richiedere rispettivamente l'elenco dei libri pubblicati in un determinato anno o scritti da un determinato autore. Tutti i DS devono gestire queste keyword obbligatoriamente.

In tutte le ricerche è ammesso l'utilizzo di wildcard (ossia simbolo *, per indicare qualunque valore non esplicito). Il simbolo di * indica una qualunque sequenza (anche vuota) di caratteri, secondo la sintassi di espressioni regolari. Attenzione!!! Per ogni campo di ricerca è ammesso l'utilizzo di una sola wildcard, quindi si può ricercare "Plinio*", ma non "*nio il*"

DECISIONE: è stato limitato l'utilizzo delle wildcard ad una sola all'interno di ogni singolo campo di ricerca.

Quindi l'elenco corrispondente alla richiesta

http://www.sito.com/techweb_ds.php?req=elenco&titolo=gra*

conterrà informazioni su tutti e soli i libri il cui titolo inizia per 'gra'. Ci sarà quindi un item relativo a "grandi speranze" ma non a "la grande rapina al treno".

Il DS restituisce alla query un documento composto da un elemento radice elenco che contiene tanti elementi voce tutti uguali. L’elemento elenco riporta nell’attributo query la query che è stata effettuata per generare l’elenco stesso. Per concatenare più keyword in base alle quali è stata svolta la ricerca si è deciso di utilizzare il separatore "&" (ad es. <elenco query="titolo=XXX&autore=YYY">).

DECISIONE: nell'attributo query di elenco si utilizza il separatore "&" per contatenare più keyword.

<!ELEMENT elenco      (voce+) >
<!ATTLIST elenco
          query CDATA #REQUIRED >
<!ELEMENT voce  ANY >
<!ATTLIST voce
          richiediCon ID    #REQUIRED >

Ogni elemento voce contiene una sequenza di elementi tratti dal vocabolario ODALISK e utili per la visualizzazione dell’elenco. La scelta degli effettivi elementi utilizzati nella voce è a discrezione del DS. L’attributo richiediCon contiene un identificativo utile per richiedere al DS la scheda completa associata alla voce.

Ad esempio, il seguente è un elenco di libri del 2000:

<elenco query="annolibro=2000">
   <voce richiediCon="rec1723">
      <titolo>Buio</titolo>
      <genere>Giallo</genere>
      <autore>Dacia Maraini</autore>
      <contenuto>bla..bla...bla...</contenuto>
   </voce>
    <voce richiediCon="rec1040">
      <titolo>Atlantide</titolo>
      <genere>Avventura</genere>
      <autore>Clive Cussler</autore>
      <trama>bla..bla...bla...</contenuto></voce>
   <voce richiediCon="rec671">
      <titolo>Endymion</titolo>
      <genere>Fantascienza</genere>
      <autore>Dan Simmons</autore>
      <contenuto>bla..bla...bla...</contenuto></voce>
 </elenco>

Gli elenchi sono costruiti dinamicamente, secondo i criteri dichiarati nel catalogo del DS. Tuttavia esistono due elenchi predefiniti che tutti i DS devono gestire e corrispondenti alle keyword annolibro e libroautore.

4.2.1 Elenco dei libri pubblicati in un determinato anno

La keyword annolibro è utilizzata per richiedere l'elenco di tutti i libri di un determinato anno. La seguente richiesta produce, ad esempio, l'elenco di tutti i libri del 2000:

http://www.sito.com/techweb_ds.php?req=elenco&annolibro=2000

Il DS risponde a questa richiesta con l'elenco richiesto e per ogni libro specifica almeno titolo, autore e anno. Di seguito un esempio della risposta:

<elenco query="annolibro=2000">
   <voce richiediCon="rec1723">
      <titolo>Buio</titolo>
      <genere>Giallo</genere>
      <autore>Dacia Maraini</autore>
      <anno>2000</anno>
      <contenuto >bla..bla...bla...</contenuto >
   </voce>
    <voce richiediCon="rec1040">
      <titolo>Atlantide</titolo>
      <genere>Avventura</genere>
      <autore>Clive Cussler</autore>
      <anno>2000</anno>
      <contenuto >bla..bla...bla...</contenuto ></voce>
   <voce richiediCon="rec671">
      <titolo>Endymion</titolo>
      <genere>Fantascienza</genere>
      <autore>Dan Simmons</autore>
      <anno>2000</anno>
      <contenuto >bla..bla...bla...</contenuto ></voce>
 </elenco>

4.2.2 Elenco dei libri di un determinato autore

La keyword libroautore è utilizzata per richiedere l'elenco di tutti i libri scritti da un determinato autore. Per ogni libro, la risposta deve contenere almeno titolo, autore, anno.

4.2.3 Elenco dei libri con un determinato titolo

La keyword titololibro è utilizzata per richiedere l'elenco di tutti i libri aventi un certo titolo. Per ogni libro, la risposta deve contenere almeno titolo, autore, anno.

4.3 La scheda

La scheda contiene tutte le informazioni associate ad un documento. Queste sono organizzate in sezioni che raggruppano informazioni tra loro omogenee per uso. Importante notare che tutte le pagine prodotte dall'AC devono essere codificate come schede e formattate dal DF.

Ogni pagina prodotta dall'AC, inclusi il catalogo e gli elenchi, è un documento che deve essere formattato dal DF.

Questo vincolo impone che sia la home-page sia ogni eventuale altra pagina statica o dinamica, help, ringraziamenti, motore di ricerca, ecc., siano sempre gestite attraverso il DF.

ODALISK definisce quattro macro-categorie di elementi: contenitori, blocchi, inline e atomici, e attribuisce ciascun elemento ad una e una sola di questa categorie.

• Un elemento contenitore è un elemento di struttura, il cui scopo è di raccogliere all’interno di un unico cappello elementi difformi per natura ma omogenei per senso e applicazione. Un elemento contenitore può contenere elementi contenitore, blocco e atomico, ma non elementi inline (che possono solo stare dentro ad elementi blocco e atomico).
• Un elemento blocco è un elemento con content model misto, e contiene testo libero organizzato verticalmente (come i paragrafi di un testo). Al suo interno, oltre al testo, è possibile trovare elementi inline e atomici, ma non contenitori o altri blocchi.
• Un elemento inline è un elemento con content model misto all’interno di un elemento blocco. Esso contiene dunque testo e altri elementi, sia inline che atomici. Sono perlopiù elementi inline quelli presentazionali. Alcuni (ad esempio a) hanno uno o più attributi esplicativi.
• Un elemento atomico è un elemento con content model testo o vuoto: il contenuto di un elemento atomico è al massimo una semplice stringa a cui l’elemento attribuisce un determinato significato. Poiché ogni stringa ha al massimo un valore semantico, e non più di uno, non è possibile che elementi atomici si contengano l’uno dentro l’altro. Alcuni elementi atomici hanno content model vuoto, e in questo caso forniscono significato con la loro semplice presenza in un punto del documento, o al massimo con gli attributi che sono stati loro definiti.

Tutti gli elementi hanno associato un attributo id, che è obbligatorio per contenitori e blocchi, e facoltativo per elementi inline e atomici.

Per gli elementi contenitore vengono forniti content model precisi. Viceversa, elementi blocco, inline e atomici hanno content model generici e sempre uguali:

Un elemento blocco ha un content model misto con tutti gli elementi inline e tutti gli elementi atomici; Un elemento inline ha un content model misto con tutti gli elementi inline e atomici; Un elemento atomico ha un content model di solo testo o vuoto; Questo corrisponde alle seguenti entità parametriche:

<!ENTITY % CMblocco   "(#PCDATA | %inline; | %atomici;)*" >
<!ENTITY % CMinline   "(#PCDATA | %inline; | %atomici;)*" >
<!ENTITY % CMatomico  "(#PCDATA)" >
<!ENTITY % CMvuoto    "EMPTY" > 

Le entità %inline;, %atomici; e %blocchi; sono definite come una lista separata da virgole di tutti gli elementi inline, atomici e blocco rispettivamente.

4.3.1 Elementi contenitore

Gli elementi contenitore costituiscono l’ossatura strutturale del documento. Sono elementi contenitore i seguenti:

Si noti l'uso dell'entità %altro; nel content-model di testo. Questo perché un testo può contenere qualunque tipo di dato o informazione necessaria per esprimere pagine diverse da elenchi e schede (di libri e/o personaggi). Come detto, infatti, ogni pagina prodotta dall'AC deve essere formattata dal DF. Un testo quindi può contenere anche liste, form (ad esempio per un motore di ricerca), immagini (non di layout ma di contenuto della pagina), tabelle contenenti dati e quant'altro. Il Working Group può estendere il contenuto di %altro;, in base alle richieste dei vari team.

Inizialmente l'entità altro corrisponde a:

<!ENTITY % altro "ul | ol | img">

dove

4.3.2 Elementi blocco e inline

Gli elementi blocco sono testi liberi contenenti elementi significativi (inline e atomici) liberamente posizionati all’interno del testo. Sono elementi blocco i seguenti:

DECISIONE: si è deciso, per alzata di mano, di privare dell'accento l'elemento "curiosità"

Inoltre sono elementi di blocco i seguenti:

Gli elementi in questa seconda tabella sono utili per esprimere le schede relative alle pagine intermedie (home-page, pagine di ringraziamenti, di aiuto o altro). L'insieme di blocchi proposti può essere ovviamente esteso in base ad esigenze e preferenze discusse nel Working Group.

Dunque l’entità %blocchi; è definita come segue:

<!ENTITY  % blocchi "recensione | commento | biografia | contesto | curiosità | contenuto | h1 | h2 | h3 | p" >

Gli elementi inline sono elementi posti all’interno dei blocchi che individuano caratteristiche non esclusive di un testo. Sono perlopiù elementi presentazionali:

Dunque l’entità %inline; è definita come segue:

<!ENTITY  % inline "em | strong | a" >

4.3.3 Elementi atomici

Gli elementi atomici sottolineano aspetti semanticamente rilevanti di un testo. Alcuni sono presentazionali, alcuni sono informazioni sul documento, ma per lo più sono informazioni sul libro, autore, presonaggio di cui parla una scheda.

Sono elementi atomici i seguenti:

<autore>
John Ronald Reuel Tolkien
</autore>
o
<autore>
    <nome>John Ronald Reuel</nome>
    <cognome>Tolkien</cognome>
</autore>

DECISIONE: è stato di deciso di trattare l'elemento "autore" lasciando la possibilità di inserire il nome completo di un autore senza differenziare nome da cognome o di utilizzare opportuni elementi per distinguerli..

Dunque l’entità %atomici; è definita come la concatenazione con "|" degli elementi suddetti:

<!ENTITY  % atomici "autore | personaggio | ecc... ">

4.3.4 La scheda di un libro

I dati contenuti in una scheda dipendono dalle informazioni memorizzate nel DS. Tuttavia esistono alcune informazioni di base che ogni DS deve gestire. In particolare ogni DS è obbligato a fornire una scheda per ogni libro, contenente un set minimale di informazioni.

Il seguente esempio mostra i dati (e la struttura obbligatoria) di una scheda-libro. Il Working Group può estendere, correggere o specificare questi dati. Tuttavia è importante definire l'organizzazione e i dati atomici di una o più schede che tutti i DS gestiscono obbligatoriamente.

<dati>

<anno>1937</anno>

<titololibro>Lo Hobbit</titololibro>

<titolooriginale>The Hobbit or There and Back Again</titolooriginale>

<genere>Fantasy</genere>

<autore>John Ronald Reuel Tolkien</autore>

<personaggio>Bilbo Baggins</personaggio>

<personaggio>Gandalf</personaggio>

<personaggio>Thorin</personaggio>

<trama>Un tranquillo hobbit della Contea viene coinvolto da un mago e tredici nani in un'avventura che lo portera' in giro per la Terra di Mezzo.</trama>

<capitoli>19</capitoli>

</dati>

4.4 Gestione Errori

Le richieste inoltrate al DS possono generare diversi errori. Per gestirli il protocollo ASD prevede un messaggio di errore che riporta un codice ed una descrizione human-readable per l’errore. Il messaggio deve essere validato dal seguente DTD:

<!ELEMENT errori (errore+)>
<!ELEMENT errore (codice, descrizione)>
<!ELEMENT codice (#PCDATA)>
<!ELEMENT descrizione %inline;>

Il seguente frammento XML riporta un esempio di messaggio di errore:

<errori>
    <errore>
       <codice>00</codice>
       <descrizione>DS non disponibile.</descrizione>
    </errore>
    ...
</errori>

Viene riportata di seguito una tabella con gli errori e le relative descrizioni:

Modifiche rispetto alla versione precedenti

In data 09052006 mi sono incontrato con (in ordine di apparizione) Jacopo Zingoni e Silvio Peroni per aggiustare le specifiche degli schemi di validazione in RelaxNG+Schematron per l'elemento "scheda".

Ecco (tutte?) le modifiche rilevanti:

• 0) c'è la possibilità di inserire svariati tag html all'interno degli elementi contenuti in "testo", bisogna assolutamente mettersi d'accordo su quali effettivamente utilizzare; per ora sono stati levati quelli per i quali si è ritenuto assolutamente impossibile un utilizzo, ma su quelli rimasti ci sono ancora dei dubbi;

• 1) l'elemento "dati", da spefiche, era opzionale; ci è parso giusto renderlo obbligatorio per evitare di creare schede assolutamente inutili;

• 2) l'unico elemento obbligatorio dentro a "dati" è "titolo";

• 3) si è operata una netta distinzione tra gli elementi ripetibili e non all'interno di "dati";

• 4) sono stati assegnati gli attributi "title" e "href" ad elementi contenuti in "dati" per i quali avesse un senso utilizzarli; in merito a questo punto c'e' una discussione ancora in atto per creare qualcosa di coerente con quanto detto alla scorsa riunione riguardo al DF, quindi prendeteli con le pinze per ora.

• 5) probabilmente è da rivedere l'elemento "copertina" per quanto riguarda i suoi attributi: per ora sono obbligatori "src" e "alt" e opzionali "href" e "title".

• 6) è stato permesso un content model misto all'interno degli elementi contenuti in "testo", per cui è possibile che si presentino questi tre casi per un elemento, ad esempio "personaggio":
  • al primo livello di annidamento dentro a "dati";
  • al primo livello di annidamento dentro a "dati" e dentro uno (o più) degli elementi contenuti in "testo";
  • solo dentro ad uno (o più) degli elementi contenuti in "testo". Fate attenzione, quindi, agli XPath che utilizzate per reperire tali informazioni!

• 7) per quanto riguarda gli elementi all'interno di "testo" (quindi "contenuto", "recensione, "commento", ecc.), si è deciso di aggiungere degli attributi che qualificassero in qualche modo da dove giungono i contenuti degli elementi medesimi. In particolare tali attributi sono "originale", "fonte", "autore" e "href" e contengono:
  • originale = la stringa "true" o "false";
  • fonte = una stringa che riporta il nome della fonte da cui sono tratti i dati;
  • autore = una stringa che identifica l'autore dell'informazione;
  • href = un URI alla fonte di informazione.

Attenzione! Posto che "autore" è opzionale, vi è una regola di Schematron che impone i seguenti limiti:

• • se "originale" è uguale a "true", allora non devono essere presenti "fonte" o "href";
  • se "originale" è uguale a "false", allora deve esserci almeno "fonte".

• 8) per il gaudio di, suppongo, al massimo 8 persone è stato aggiunto finalmente il tanto agognato elemento "luogo" :D.

Elenco delle modifiche creato automaticamente in base ai

<p class="empty">...</>

-- JacK - 29 Apr 2006

• Set ALLOWTOPICVIEW =
• Set ALLOWTOPICCHANGE = JacK, NicolaPoluzzi
• Set ALLOWTOPICRENAME = JacK