4.3

Sezione 4: Sviluppatori

Q 4.3: Cosa sono i termini “valido, senza DTD, e ben formato”?

Ben formato significa sintatticamente corretto; valido significa conforme ad un DTD o uno Schema

 

XML ti permette di usare uno Schema o Document Type Definition (DTD) per descrivere il markup (elementi e altri costrutti) disponibili in qualsiasi tipo di documento specifico. Tuttavia, il design e la costruzione di Schemi e DTD possono essere complessi e non banali, quindi XML ti permette di lavorare anche senza uno. Le operazioni senza DTD permettono di inventare markup senza dover definirli formalmente, a patto che segui le regole della buona forma della sintassi XML.

Per fare in modo che funzioni, viene supposto che un file DTD definisca il proprio markup puramente dall’esistenza e posizione di elementi dove li hai creati. Quando un applicazione XML incontra un file senza DTD, costruisce il suo modello interno della struttura del documento mentre lo legge, dato che non ha nessuno Schema o DTD per capire cosa aspettarsi. Non devono dunque esserci sorprese o sintassi ambigua. Per fare questo, il documento deve essere ‘ben formato’ (deve seguire le regole).

Per capire perché questo concetto è necessario, dai un’occhiata a standard HTML come esempio:

  • L’elemento <img>viene dichiarato (nel [SGML] senza DTD per HTML) come EMPTY, quindi non deve avere tag di chiusura (non esiste </img>);
  • Molti altri elementi HTML (come <para>) ti permettono di omettere il tag di chiusura per motivi di sinteticità.
  • Se un elaboratore XML leggere un file HTML senza sapere questo (dato che non sta usando un DTD), e incontra un  <img>o un <para> (o qualsiasi altro tag di apertura), non potrebbe sapere se aspettarsi o no un tag di chiusura. Questo rende impossibile sapere se il resto del file è corretto o no, dato che ora non sa se sia all’interno di un elemento o se ha finito con questo.

I documenti ben formati dunque hanno bisogno di tag di apertura e chiusura per ogni elemento normale, e qualsiasi elemento EMPTY dovrà essere reso chiaro, sia usando tag di apertura e chiusura normali, o mettendo uno slash al nome del tag di apertura prima della > di chiusura come segno che non ci sarà un tag di chiusura separato.

Tutti i documenti XML, sia senza DTD e validi, devono essere ben formati. Devono iniziare con una Dichiarazione XML se necessaria (per esempio, identificare la codifica del carattere o usare la Dichiarazione di Documento Autonomo):

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?> 
<foo> 
  <bar>...<blort/>...</bar> 
</foo> 

David Brownell scrive:

Il XML che è solo ben formato non ha bisogno di usare una Dichiarazione di Documento Autonomo. Tali dichiarazioni esistono per permettere alcune velocizzazioni durante l’elaborazione dei documenti ignorando entità di parametro esterne – in pratica, non puoi affidarti a dichiarazioni esterne in documenti autonomi. I tipi che sono rilevanti sono entità e attributi. I documenti autonomi non richiedono alcun tipo di normalizzazione o defaulting del valore di attributo, altrimenti sarebbero invalidi.

È anche possibile usare una Dichiarazione di Tipo di Documento con un file senza DTD, anche se non ci sono Tipi di Documento a cui fare riferimento:

Richard Lander scrive:

Se hai bisogno di entità di carattere [oltre alle cinque incorporate] in un file senza DTD, puoi dichiararli in un subset interno senza fare riferimento a nulla oltre che il tipo di elemento radice:

<?xml version="1.0" standalone="yes"?> 
<!DOCTYPE example [ 
<!ENTITY mdash "&mdash;"> 
]> 
<example>Hindsight&mdash;a wonderful thing.</example>

Dunque… ecco le regole:

XML ben formato

  • Tutti i tag devono essere bilanciati: ovvero, ogni elemento che potrebbe contenere dati carattere o sotto-elementi deve presentare sia tag di apertura che di chiusura (non viene accettata l’omissione eccetto per elementi EMPTY, vedi sotto);
  • I valori di attributi devono essere dentro virgolette. Potrebbe essere usato il carattere virgoletta singola (l’apostrofo) se il valore contiene un carattere virgoletta doppia, e viceversa. Se hai bisogno di virgolette isolate nonché di dati puoi usare &apos;o &quot;. Non usare in nessuna circostanza una le virgolette (‘ricce’) tipografiche automatizzate sostituite da qualche elaboratore di testo per citare valori di attributo.
  • Qualsiasi elemento EMPTY (ad es. quelli senza tag di chiusura come  <img>, <hr>, e <br>e altri di HTML) devono finire con/> oppure devono avere l’aspetto di un elemento non EMPTY avendo un vero tag di chiusura (ma nessun contenuto). Esempio: <br> diventerebbe <br/> oppure <br> </br> (senza niente all’interno).
  • Non deve esserci nessun carattere di inizio markup isolato (<o &) nei tuoi dati di testo. Devono essere dati come &lt; e &amp; rispettivamente, e la sequenza ]]> potrebbe verificarsi solo come fine della sezione marcata CDATA: se la stai usando per qualsiasi altro motivo deve essere data come ]] &gt;.
  • Gli elementi devono nidificare propriamente fra loro (nessun markup sovrapposto, come per HTML);
  • I documenti DTD ben formati potrebbero usare attributi su qualsiasi elemento, ma si suppone che gli attributi siano di tipo CDATA. Non puoi usare tipi di attributo ID/IDREF per riferimenti incrociato controllato dal parser in documenti senza DTD.
  • Si considera che i file XML senza DTD abbiano &lt;, &gt;, &apos;, &quot;, and &amp;predefiniti e dunque disponibili all’uso. Con un DTD, tutte le entità di carattere usate devono essere dichiarate, fra cui queste cinque.

Peter Flynn scrive:

XML Valido

File XML validi sono file ben formati che hanno una Definizione di Tipo di Documento (DTD) o Schema e che sono conformi ad essi. Devono essere già ben formati, dunque valgono tutte le regole sopra.

Un file valido inizia con una Dichiarazione di Tipo di Documento che specifica un DTD, o codice che specifica uno Schema W3C. Potrebbe avere una Dichiarazione XML aggiunta.

<!DOCTYPE advert PUBLIC	
   "+//Silmaril//DTD Foo Corp Advertisements//EN"
   "http://www.foo.org/ad.dtd"> 
<advert>...</advert>

Le specifiche XML predefiniscono una Dichiarazione SGML per XML che è fissa per tutte le istanze e dunque programmato nel software XML e ma specificato separatamente (eccetto quando si usa un convalidatore scambiabile SGML/XML come onsgmls: vedi sotto).

Peter Flynn scrive:

La Dichiarazione per XML è stata rimossa dal testo delle Specifiche ma è disponibile come documento separato). Dato che questa sembra soffre occasionalmente di bitrot e negligenza, ecco una copia qui (WebSGML TC) e qui (Extended Naming Rules TC), e una versione per onsgmls qui.

Il DTD specificato deve essere accessibile dall’elaboratore XML usando un UTI fornito nel identificatore SYSTEM, che sia disponibile in locale (ovvero l’utente ha già una copia sul disco) o che sia recuperabile attraverso la rete. Nota che le specifiche DTD devono essere URI (locali, relativi, o assoluti). I riferimenti a filesystem proprietario-specifici (ad es. C:\dtds\my.dtd non sono URI e non possono essere usati: usa dunque il formato file:///C|/dtds/my.dtd.

È possibile (molte persone direbbero che p preferibile) fornire un Identificatore Pubblico Formale con la parola chiave PUBLIC, e usare un Catalogo XML per dereferenziarlo, ma le Specifiche richiedono un Identificatore SYSTEM dunque questo deve essere comunque fornito dopo l’identificatore PUBLIC: non sono necessarie ulteriori parole chiave. Un identificatore PUBLIC costituisce una dichiarazione di proprietà solo dell’identificatore, non del DTD stesso (anche se in molti casi è implicato).

 
<!DOCTYPE advert PUBLIC	
   "+//Silmaril//DTD Foo Corp Advertisements//EN"
   "http://www.foo.org/ad.dtd"> 
<advert>...</advert>

Il test per la validità è che un parser di convalida non trova errori nel file: deve conformarsi assolutamente alle definizioni e dichiarazioni nel DTD.

Gli Schemi XML (W3C) non sono solitamente direttamente collegati dall’interno di un’istanza di documento XML nello steso modo dei DTD: lo Schema rilevante (file XSD) per un’istanza di documento è normalmente specificata separatamente dal parser, sia dal riferimento del file di sistema, o usando un  Target Namespace.

Leave a Comment

Your email address will not be published. Required fields are marked *