Un documento HTML valido dichiara quale versione di HTML è usata nel documento. La dichiarazione del tipo di documento menziona la definizione del tipo di documento (DTD) in uso per il documento (si veda [ISO8879]).
L’HTML 4.01 specifica tre DTD, così gli autori devono includere nei loro documenti una delle seguenti dichiarazioni del tipo di documento. Le DTD differiscono negli elementi che esse supportano.
•La DTD rigorosa di HTML 4.01 include tutti gli elementi e gli attributi che non sono stati disapprovati o che non appaiono nei documenti con frame. Per documenti che usano questa DTD, si adoperi la seguente dichiarazione del tipo di documento:
•La DTD transitoria di HTML 4.01 include tutto ciò che fa parte della DTD rigorosa più gli elementi e gli attributi disapprovati (la maggior parte dei quali riguardano la presentazione visuale). Per documenti che usano questa DTD, si adoperi la seguente dichiarazione del tipo di documento:
•La DTD a frame di HTML 4.01 include la DTD transitoria completa più i frame. Per documenti che usano questa DTD, si adoperi la seguente dichiarazione del tipo di documento:
L’URI presente in ciascuna dichiarazione del tipo di documento consente ai programmi utente di scaricare la DTD e tutti gli insiemi di entità necessari. I seguenti URI (relativi) rimandano alle DTD e agli insiemi di entità per l’HTML 4:
•strict.dtd — DTD rigorosa predefinita
•loose.dtd — DTD non rigorosa
•frameset.dtd — DTD per documenti con frame
•HTMLlat1.ent — Entità latin-1
•HTMLsymbol.ent — Entità symbol
•HTMLspecial.ent — Entità speciali
Il legame tra identificatori pubblici e file può essere specificato usando un file di catalogo che segue il formato raccomandato dall’Oasis Open Consortium (si veda [OASISOPEN]).
Un file di catalogo esemplificativo per HTML 4.01 è incluso all’inizio della sezione sulle informazioni di riferimento SGML per HTML. Le ultime due lettere della dichiarazione indicano la lingua della DTD. Per l’HTML, questa è sempre l’inglese (“EN”).
l’idea di questo articolo è mettere in relazione tre zone della programmazione di un pagina HTML e realizzare un prodotto nuovo patendo dalle interazioni possibili. innanzitutto la DTD va considerata come un’area della programmazione che in SGML consente di ricevere una serie di autorizzazioni direttamente nella propria pagina. si tratta di vere e proprie autorizzazioni, non di indicazioni o semplici istruzioni, dunque potete tutti immaginare quante possibilità di sviluppo una autorizzazione formulata ad hoc per una pagina HTML consente. La DTD infatti è una traduzione , un passaggio intermedio tra l’SGML e la programmazione ad oggetti o la programmazione a cascata. quindi se volessimo figurare le nostre ipotesi graficamente in questo momento noi riceveremmo codici da un’area alta e sinistra che invaderebbe la nostra pagina con un modello, diciamo, a cascata.
In informatica, entro un programma, con Application Programming Interface (API) si indica un insieme di procedure (in genere raggruppate per strumenti specifici) atte all’espletamento di un dato compito; spesso tale termine designa le librerie software di un linguaggio di programmazione.
Quindi esiste anche la possibilità non solo di usare dei pacchetti preconfezionati, ma ovviamente, di impacchettare le strutture che vengono a crearsi, alzando il livello della programmazione della pagina intera, cioè rendendo interattive le sue componenti e quindi sviluppando un interazione di secondo livello.
Esistono vari design model per le API. Le interfacce intese per la massima velocità di esecuzione spesso consistono in una serie di funzioni, procedure, variabili e strutture dati.
Esistono anche altri modelli come gli interpreti usati per valutare le espressioni come con ECMAScript/JavaScript.
Una buona API fornisce una “scatola nera”, cioè un livello di astrazione che evita al programmatore di sapere come funzionano le API ad un livello più basso.
Questo permette di riprogettare o migliorare le funzioni all’interno dell’API senza cambiare il codice che si affida ad essa
In generale l’analisi dell’implementazione di una API per produrne una compatibile costituisce una violazione alla legge. Questa tecnica è chiamata ingegneria inversa.
La situazione legale in questi casi presenta ambiguità quindi conviene affrontare il problema prima che l’attività di ingegneria inversa sia iniziata. Per esempio, una API può contenere a sua volta un brevetto.
La finalità è ottenere un’astrazione a più alto livello, di solito tra l’hardware e il programmatore o tra software a basso e quello ad alto livello semplificando così il lavoro di programmazione.
Le API permettono infatti di evitare ai programmatori di riscrivere ogni volta tutte le funzioni necessarie al programma dal nulla, ovvero dal basso livello, rientrando quindi nel più vasto concetto di riuso di codice.
Le API stesse rappresentano quindi un livello di astrazione intermedio: il software che fornisce una certa API è detto implementazione dell’API.
Posix
Il motivo per cui porto come esequesto linguaggio è proprio perché consente di di standardizzare parti del nostro lavoro (oppure il lavoro per intero)
trattandosi di “standardizzazione” qui ci spostiamo direttamente nella zona opposta a quella di partenza, cioè in alto a destra, per svolgere un lavoro di output che ci consenta di trasmettere ciò che abbiamo realizzato ma anche di assicurarci che resista nel tempo.
ovvio che trattandosi di un altro linguaggio, non di HTML, questo è solo un esempio, se volessimo imitarlo noi dovremmo usare forse Apache o delle RFC ottimamente formulate.
Dovremmo insomma ottenere che i nostri codici vengano riconosciuti come standard e … onestamente non è un passaggio semplice.Però se pensiamo di nuovo di avere ottenuto una buona autorizzazione e al contempo di avere dei mezzi per quantomeno richiedere una standardizzazione di qualsiasi grado, ebbene questo scambio di codici ci permetterebbe di avere nella nostra pagina un livello di programmazione decisamente alto.
Poiché esistono molte varianti di API, nel 1985 è stato creato un progetto finalizzato alla creazione di uno standard. La famiglia che racchiude questi standard prende il nome di Posix acronimo di Portable Operating System Interface for Unix,
il cui nome è stato ideato da Richard Stallman dopo la richiesta da parte dell’IEEE di un nome di facile memorizzazione.
Esempio di utilizzo
Si può pensare ad un’applicazione che scriva le parole “Hello world” su uno schermo con vari livelli di astrazione.
Scrivere tutto da soli:
Disegnare su un foglio le forme delle lettere H, e, l, l, o, W, o, r, l, d.
Preparare una matrice di quadrati bianchi e neri avente la forma di ognuna delle lettere
Ideare un modo per programmare la CPU in modo che ponga questa matrice nel frame buffer della scheda video.
Predisporre la scheda video per generare il segnale corretto a partire dal contenuto frame buffer.
Utilizzare un sistema operativo per effettuare parte del compito:
Caricare in memoria una struttura dati chiamata “font” fornita dal sistema operativo.
Far visualizzare al sistema operativo una finestra vuota.
Far disegnare al sistema operativo il testo “Hello World” sulla finestra utilizzando il font caricato.
Utilizzare un’applicazione (che a sua volta utilizza il sistema operativo) per tutto il lavoro:
Scrivere un documento HTML contenente le parole “Hello World”.
Aprire il documento con un web browser.
Ovviamente, l’approccio del primo livello richiede molti passaggi ed ognuno di questi è molto più complesso di quelli dei livelli successivi. Altro svantaggio del primo approccio è che è poco pratico utilizzarlo nel caso in cui sia necessario
visualizzare una certa quantità di informazioni sullo schermo; col secondo approccio l’operazione è molto più semplice, e nel terzo è sufficiente scrivere “Hello World”. In genere utilizzare API di livello più alto comporta una certa perdita
di flessibilità; per esempio, potrebbe essere molto difficile a livello di web browser ruotare attorno ad un punto un testo con i bordi lampeggianti, mentre questo compito potrebbe essere svolto in modo semplice ad un livello più basso.
Questa differenza è un tipico esempio di compromesso che si può incontrare utilizzando un’API.
Esempi di API
L’interfaccia di chiamate al BIOS del PC
I Document Object Model di varie applicazioni come l’HTML
La Single UNIX Specification
La Windows API di Microsoft
L’API Java 2 Enterprise Edition Java EE
L’interfaccia ASPI per i dispositivi SCSI
Le API Carbon e Cocoa per il Macintosh macOS Server
API e Web service
Common Object Request Broker Architecture (CORBA)
Java APIs for Integrated Networks (JAIN)
Simple Network Management Protocol (SNMP)
Universal Plug and Play (UPnP)
Google APIs by Google Inc.
Mantle, API di basso livello sviluppate da AMD come alternativa a DirectX e OpenGL
Java Telephony API, API di Java per la gestione di call center distribuiti.
Contenuto misto dell’elemento
Se si vuole definire una regola che consenta a un elemento di contenere testo o altri elementi in qualche combinazione si usa un modello a contenuto misto.
Sintassi > Esempio: > ]> Nota
Ecco, per una pagina HTML un contenuto misto di questo tipo è l’ideale, una sintassi che è la struttura legale che regola tutte le sue componenti, un metodo, una indicazione di come dobbiamo comportarci, di che strumenti dobbiamo utilizzare e , infine, un elenco infinito di valori, di dettagli di azioni che possiamo compiere. se pensiamo che i primi ad essere modificati da una DTD sono i metatag, e se consideriamo che i metatag definiscono i behaviour non solo della nostra pagina ma anche di come la pagina esiste ne l web, immediatamente ci rendiamo conto che tutta la struttura adesso è tutelata proprio dalle richieste che abbiamo ricevuto e al contempo dalla possibilità di essere analizzata in uscita. come se avesse due mollette alle quali restare appesa.
