Descrizione sommaria: Linguaggio di
Marcatura Matematica (MathML) Versione 2.0
Precedente: 6 Caratteri, entità e
font
Successivo: 8 Modello a oggetti dei
documenti per il MathML
7 L'interfaccia del MathML
7.1 Incorporare il MathML in
altri documenti
7.1.1 Il MathML e gli spazi di
nomi
7.1.2 L'elemento
math
di livello principale
7.1.3 Invocare
gli elaboratori del MathML
7.1.4 Mescolare e collegare il MathML e
l'HTML
7.2 Generare, elaborare ed
interpretare il MathML
7.2.1 Conformità al MathML
7.2.2 Gestione degli errori
7.2.3 Attributi per dati non
specificati
7.3 Estensioni future
7.3.1 Macro e
fogli di stile
7.3.2 Estensioni
XML al MathML
Per essere efficace, il MathML deve funzionare bene con un'ampia varietà di interpreti, elaboratori, traduttori e programmi di scrittura. Questo capitolo copre alcuni dei problemi di interfaccia coinvolti nel generare e riprodurre il MathML. Poiché il MathML esiste principalmente per codificare la matematica nei documenti Web, forse i problemi di interfaccia più importanti sono legati ad incorporare il MathML nell'HTML [HTML4.0] e nell'XHTML [XHTML1.0] e [XHTML1.1].
Ci sono tre tipi di problemi di interfaccia che sorgono nell'incorporare il MathML in altri documenti XML. Primo, il MathML deve essere semanticamente integrato. La marcatura del MathML deve essere riconosciuta come contenuto XML incorporato valido, e non come un errore. Questa è soprattutto una questione di gestire gli spazi di nomi nell'XML [Namespaces].
Secondo, nel caso dell'HTML/XHTML, la riproduzione del MathML deve essere integrata nel browser. Alcuni browser implementano già la riproduzione del MathML in modo nativo, e ci si può aspettare che più browser lo faranno in futuro. Al tempo stesso, altri browser hanno sviluppato infrastrutture per facilitare la riproduzione del MathML e altro contenuto XML incorporato da software di terzi. Usare questi meccanismi dipendenti dal browser richiede generalmente un po' di marcatura di interfaccia aggiuntiva di qualche tipo perché si attivino.
Terzo, altri strumenti per generare ed elaborare il MathML devono poter intercomunicare. Sono stati sviluppati o sono in fase di sviluppo vari strumenti per il MathML, compresi programmi di scrittura, traduttori, sistemi di computer algebra e altro software scientifico. Comunque, poiché le espressioni MathML tendono ad essere lunghe, ed è facile sbagliare se si inseriscono a mano, deve essere data un'enfasi speciale ad assicurare che il MathML possa essere facilmente generato da strumenti di conversione e di creazione amichevoli, e che questi strumenti lavorino insieme in un modo affidabile e indipendente dal produttore e dalla piattaforma.
Il gruppo di lavoro per la Matematica del W3C fornisce supporto ai produttori di software che vogliano sviluppare strumenti per il MathML di ogni tipo. Il gruppo di lavoro tiene d'occhio la mailing list pubblica www-math@w3.org e cercherà di rispondere a domande sulle specifiche MathML. Il gruppo di lavoro collabora con gruppi di sviluppatori e utenti MathML. Per informazioni su strumenti MathML, applicazioni e attività di supporto agli utenti, si consulti la pagina principale del Gruppo di Lavoro per la Matematica del W3C.
Sebbene il MathML si possa usare da solo come linguaggio per scambiare espressioni matematiche tra applicazioni compatibili con il MathML, l'uso primario anticipato del MathML è codificare espressioni matematiche all'interno di documenti più grandi. Il MathML è ideale per incorporare espressioni matematiche in altre applicazioni dell'XML.
In particolare, ci concentriamo qui sulla meccanica di incorporare il MathML nell'XHTML. L'XHTML [XHTML1.0] è una Direttiva del W3C pubblicata di recente che formula una famiglia di attuali e futuri tipi di documento basati sull'XML e moduli che riproducono, specializzano ed estendono l'HTML 4. Sebbene l'HTML 4 [HTML4.0] sia il linguaggio dominante sul Web attualmente, si può anticipare uno spostamento dall'HTML 4 all'XHTML. In realtà, l'XHTML viene già riprodotto correttamente negli interpreti per l'HTML 4.
Poiché il MathML e l'XHTML condividono un modello XML comune, gli spazi di nomi forniscono un meccanismo standard per incorporare il MathML nell'XHTML. Sebbene alcuni interpreti HTML popolari supportino anche l'inclusione del MathML direttamente nell'HTML 4 come "isole di dati XML", il punto di vista che adottiamo qui è che questa è una strategia transitoria, e non la portiamo avanti. Si consulti la documentazione del proprio interprete HTML per informazioni specifiche sul supporto per incorporare l'XML nell'HTML.
Incorporare il MathML in documenti basati sull'XML in generale, e sull'XHTML in particolare, è una questione di gestione degli spazi di nomi. Si veda la Direttiva del W3C "Spazi di nomi nell'XML" [Namespaces] per maggiori dettagli.
Uno spazio di nomi XML è una collezione di nomi identificata da una risorsa URI. L'URI dello spazio di nomi MathML è:
http://www.w3.org/1998/Math/MathML
Usando gli spazi di nomi, incorporare un'espressione MathML in un documento XML più grande è puramente una questione di identificare la marcatura MathML come residente nello spazio di nomi del MathML. Questo può essere fatto sia identificando esplicitamente ogni nome di elemento MathML allegando ad esso un prefisso dello spazio di nomi, che dichiarando uno spazio di nomi predefinito su un elemento che lo include.
Per dichiarare uno spazio di nomi si usa un attributo
xmlns
, o un attributo con un prefisso
xmlns
. Quando si usa l'attributo xmlns
da
solo, definisce lo spazio di nomi per l'elemento sul quale appare, e
per ogni elemento figlio.
Esempio:
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mrow>...</mrow> </math>
Quando l'attributo xmlns
è usato come prefisso,
dichiara un prefisso che può poi essere usato per associare
esplicitamente altri elementi ed attributi con uno spazio di nomi
particolare.
Esempio:
<body xmlns:m="http://www.w3.org/1998/Math/MathML"> ... <m:math><m:mrow>...</m:mrow></m:math> ... </body>
Questi due metodi di dichiarazione degli spazi di nomi possono
essere usati insieme. Per esempio, usando sia un prefisso di spazio di
nomi esplicito esteso a tutto il documento che dichiarazioni di spazi
di nomi predefiniti sui singoli elementi math, è possibile
localizzare la marcatura relativa agli spazi di nomi all'elemento
math
di livello principale. Questo è importante
anche per l'implementazione con alcuni interpreti HTML, poiché
allegare i comportamenti di riproduzione ad un elemento attualmente
richiede un prefisso di spazio di nomi esplicito per questi
browser. Allo stesso tempo, vari strumenti di scrittura MathML non
riconoscono ancora gli spazi di nomi, e per questo la
possibilità di usare marcatura senza prefissi è
altrettanto desiderabile a breve termine.
Esempio:
<body xmlns:m="http://www.w3.org/1998/Math/MathML"> ... <m:math xmlns="http://www.w3.org/1998/Math/MathML"> <mrow>...<mrow> </m:math> ... </body>
L'uso dei prefissi degli spazi di nomi crea un problema per la convalida DTD dei documenti che incorporano il MathML. La convalida DTD richiede la conoscenza dei nomi letterali (eventualmente prefissi) degli elementi usati nel documento. Comunque, gli spazi di nomi nella Direttiva XML [Namespaces] permettono che i prefissi siano cambiati in punti arbitrari nel documento, poiché i prefissi degli spazi di nomi possono essere dichiarati su ogni elemento.
Il metodo `storico' per superare questo divario era scrivere una DTD con un prefisso fissato, o nel caso dell'XHTML e del MathML senza prefisso, e richiedere che la forma specificata dovesse essere usata in tutto il documento. Comunque, ciò è piuttosto restrittivo per una DTD modulare che è pensata per l'uso in congiunzione con un'altra DTD, che è esattamente la situazione del MathML nell'XHTML. In sostanza, la DTD del MathML dovrebbe `allocare' un prefisso per se stessa e sperare che nessun altro modulo usi lo stesso prefisso per evitare collisioni di nome, perdendo così uno dei principali vantaggi degli spazi di nomi dell'XML.
Una strategia per risolvere questo problema è far sì che ad ogni nome di elemento della DTD si possa accedere tramite un riferimento ad entità. Questo vuol dire che dichiarando un paio di entità per specificare il prefisso prima che la DTD sia caricata, il prefisso può essere scelto dall'autore di un documento, e DTD composte che includono più moduli possono, senza cambiare le DTD dei moduli, specificare prefissi unici per ciascun modulo per evitare collisioni. La DTD del MathML è stata progettata in questo modo. Si veda la Sezione A.1 [La DTD del MathML], [Modularization] e [Building] per dettagli.
Un altro problema nasce nel caso che si usino prefissi espliciti sull'elemento math di livello principale, mentre per altri elementi MathML si usa uno spazio di nomi predefinito. In questo caso si vuole che il modulo MathML sia incluso nell'XHTML con il prefisso vuoto. Comunque, il file `driver' DTD che definisce l'inclusione del modulo MathML avrebbe bisogno allora di definire un nuovo elemento di nome m:math. Questo permetterebbe all'elemento math di livello principale di usare un prefisso esplicito, per includere comportamenti di riproduzione nei browser attuali, mentre il contenuto non avrebbe bisogno di un prefisso esplicito, per facilità di interoperabilità tra strumenti di scrittura, ecc.
Sebbene l'uso degli spazi di nomi per includere il MathML in altre applicazioni XML sia completamente descritto dalle rilevanti direttive del W3C, si richiede ancora un certo grado di pragmatismo attualmente. Il supporto per l'XML, gli spazi di nomi e i comportamenti di riproduzione negli interpreti HTML popolari non è sempre pienamente allineato con le Direttive del W3C. In alcuni casi il software precede lo standard rilevante, e in altri casi gli standard rilevanti non sono ancora completi.
Durante il periodo transitorio in cui qualche prodotto software può non essere pienamente compatibile con gli spazi di nomi, alcune pratiche convenzionali potranno semplificare i problemi di compatibilità. Dopo aver visionato un certo numero di interpreti HTML e altre applicazioni software compatibili con il MathML, offriamo i seguenti suggerimenti.
math
.
Esempi.
<body> ... <m:math xmlns:m="http://www.w3.org/1998/Math/MathML"> <m:mrow>...<m:mrow> </m:math> ... </body>
Oppure
<body> ... <math xmlns="http://www.w3.org/1998/Math/MathML"> <mrow>...<mrow> </math> ... </body>
Si noti che questi suggerimenti da soli possono non essere sufficienti per creare pagine Web funzionali che contengono marcatura MathML. Sarà generalmente il caso che si renderà necessaria della marcatura aggiuntiva estesa a tutto il documento. Può essere necessario anche ulteriore lavoro per rendere tutte le istanze MathML in un documento compatibili con le dichiarazioni estese al documento. Questo è particolarmente vero quando i documenti sono creati tagliando e incollando espressioni MathML, poiché i programmi attuali non saranno probabilmente in grado di chiedere informazioni sullo spazio di nomi globale.
Si consulti la pagina principale del Gruppo di Lavoro per la Matematica del W3C per consigli sulla compatibilità e sulle implementazioni per browser attuali e altri strumenti che lavorino con il MathML.
math
di livello
principale Il MathML specifica un singolo elemento math
di
livello principale o radice, che incapsula ogni istanza della
marcatura MathML all'interno di un documento. Ogni altro contenuto
MathML deve essere all'interno di un elemento math
;
equivalentemente, ogni espressione MathML valida e completa deve
essere contenuta nei tag <math>
. L'elemento
math
deve essere sempre l'elemento più esterno in
un'espressione MathML; è un errore che un elemento
math
ne contenga un altro.
Applicazioni che restituiscono sottoespressioni di altre
espressioni MathML, per esempio come risultato di un'operazione di
copia e incolla, dovrebbero sempre includerle in una coppia di tag
<math>
. Idealmente, la presenza di tag
<math>
di apertura e chiusura dovrebbe essere
un'ottima prova euristica per il contenuto MathML. In modo simile,
applicazioni che inseriscono espressioni MathML in altre espressioni
MathML devono preoccuparsi di rimuovere i tag
<math>
dalle espressioni interne.
L'elemento math
può contenere un numero
arbitrario di schemi figli. Gli schemi figli sono riprodotti in modo
predefinito come se fossero contenuti in un elemento
mrow
.
Gli attributi dell'elemento math
sono:
macros
è fornito per rendere possibili sviluppi
futuri di meccanismi di macro più dinamici e specifici del
MathML. Il valore di quest'attributo è una sequenza di URL o
URI, separati da spazi bianchi. mode
specifica se l'espressione MathML
inclusa deve essere presentata in stile visuale o in stile in
linea. Valori permessi sono display
e inline
(predefinito). Questo attributo è disapprovato in favore del
nuovo attributo display
, o della proprietà
standard dei CSS2
`display' con gli analoghi valori block
e
inline
. display
sostituisce l'elemento
mode
, disapprovato. Specifica se l'espressione MathML
inclusa deve essere presentata in stile visuale o in stile in
linea. Valori permessi sono block
e inline
(predefinito).
Gli attributi dell'elemento math
hanno effetto
sull'intera espressione inclusa. Sono, in un certo senso, `orientati
all'interno'. Comunque, per presentare nel modo giusto il MathML in un
browser e per integrarlo nel modo giusto in un documento XHTML,
è utile anche una seconda collezione di attributi `orientati
all'esterno'.
Sebbene meccanismi generali per allegare comportamenti di presentazione agli elementi nei documenti XML siano in fase di sviluppo, restano ampie variazioni nella strategia e nel livello di implementazione tra i vari interpreti HTML esistenti. Di conseguenza, il resto di questa sezione descrive attributi e funzionalità desiderabili per integrare moduli di visualizzazione prodotti da terzi con interpreti HTML:
Nei browser dove il MathML non è supportato in modo nativo, anticipiamo che la riproduzione del MathML sarà eseguita tramite oggetti incorporati come plug-in, applet o applicazioni di aiuto. La direzione che è cominciata ad emergere per invocare software di presentazione ed elaborazione prodotto da terzi è illustrata nella Bozza di Lavoro del W3C "Estensioni di comportamento ai CSS" [Behaviors].
Le estensioni di comportamento usano i meccanismi di collegamento
dei CSS per allegare componenti eseguibili agli elementi. Tipicamente,
i componenti eseguibili coinvolgono codice script che manipola il DOM
per instanziare altri componenti di elaborazione del MathML. Usando
implementazioni sperimentali per estensioni di comportamento negli
interpreti HTML attuali, è possibile allegare componenti di
elaborazione agli elementi math
che usano applet o
plug-in per riprodurre la marcatura MathML in una pagina XHTML.
Al W3C si sta svolgendo un lavoro sulle estensioni al comportamento dei CSS, e implementazioni esistenti devono essere considerate come sperimentali attualmente. Comunque, questo offre una direzione molto promettente per invocazioni potenti e flessibili di elaboratori di MathML prodotti da terzi.
I tipi MIME offrono una strategia alternativa che può essere
usata anche negli interpreti HTML attuali per invocare un riproduttore
per il MathML. Questo è principalmente utile quando si fa
riferimento a file separati che contengono marcatura MathML
proveniente da un elemento EMBED
o
OBJECT
. Il Gruppo di Lavoro per la Matematica del W3C
suggerisce che al MathML generico sia assegnato il tipo MIME
text/x-mathml
, e per il registry dei browser, suggeriamo
di usare l'estensione standard .mml
. In MathML 1.0 come
tipo MIME suggerito era stato dato il tipo
text/mathml
. Comunque, l'assegnazione di tipi MIME ad
applicazioni XML è un argomento venuto in discussione nel
frattempo. Perciò, a cominciare dal MathML 2.0, suggeriamo di
usare invece il tipo MIME sperimentale e meno regolato
text/x-mathml
.
Anche se la riproduzione delle espressioni MathML tipicamente avviene localmente in un browser, altre funzioni di elaborazione del MathML avvengono in modo più naturale in altre applicazioni. Compiti particolarmente comuni includono l'apertura di un'espressione MathML in un programma di scrittura di equazioni o in un sistema di computer algebra.
Attualmente, non c'è un modo standard di scegliere tra varie applicazioni che possono essere usate per riprodurre o elaborare il MathML incorporato. Come il lavoro procede riguardo al coordinamento tra browser ed elementi incorporati e il Modello a Oggetti dei Documenti [DOM], fornire questo tipo di funzionalità dovrebbe essere una priorità. Sia gli autori che i lettori dovrebbero essere in grado di indicare una preferenza su quale applicazione MathML usare in un dato contesto. Per esempio, si potrebbe immaginare che una qualche azione del mouse su un'espressione MathML faccia sì che un browser presenti al lettore un menu, mostrando i vari tipi di elaborazione MathML disponibili sul sistema e gli elaboratori MathML raccomandati dall'autore.
Poiché il MathML spesso è generato da strumenti di
scrittura, è particolarmente importante che aprire
un'espressione MathML in un programma di scrittura sia facile da fare
e da implementare. In molti casi, sarà desiderabile che uno
strumento di scrittura registri alcune informazioni sul suo stato
interno insieme a un'espressione MathML, in modo che un autore possa
ripartire a scrivere da dove era rimasto. Le specifiche MathML non
contengono esplicitamente un modo per registrare informazioni sullo
strumento di scrittura. In alcune circostanze, può essere
possibile includere informazioni sul programma di scrittura che si
applicano a un intero documento nella forma di meta-dati; lettori
interessati sono incoraggiati a consultare l'Attività sui
Meta-dati del W3C per informazioni attuali sui meta-dati e sulla
definizione di risorse. Per codificare informazioni di stato sui
programmi di scrittura che si applicano ad una particolare istanza
MathML, i lettori possono riferirsi al possibile uso dell'elemento
semantics
per questo fine.
A breve termine, senza tener conto della metodologia, gli implementatori di applicazioni che elaborano il MathML incorporato sono incoraggiati a cercare di permettere i seguenti tipi di funzionalità:
Perché sia pienamente integrato nell'XHTML, deve essere possibile non solo incorporare il MathML nell'XHTML, ma anche incorporare l'XHTML nel MathML. Comunque, il problema di supportare l'XHTML nel MathML presenta molte difficoltà. In più, i problemi non sono specifici del MathML; sono problemi delle applicazioni XML nell'XHTML in generale. Perciò, attualmente, le specifiche MathML non permettono nessun elemento XHTML all'interno di un'espressione MathML, nonostante questo possa essere soggetto a cambiamenti in una revisione futura del MathML.
Nella maggior parte dei casi, o gli elementi XHTML non si applicano in un contesto matematico (intestazioni, paragrafi, liste, ecc.) o il MathML fornisce già funzionalità equivalenti o migliori, disegnate specificamente per il contenuto matematico (tabelle, cambiamenti di stile, ecc.). Comunque, ci sono due eccezioni notevoli.
Il MathML non ha un elemento che corrisponde all'elemento ancora a dell'XHTML. In XHTML le ancore si usano sia per creare collegamenti che per fornire locazioni alle quali i collegamenti possono essere creati. Il MathML, come applicazione XML, definisce i link usando il meccanismo descritto nella Bozza di Lavoro del W3C "Il linguaggio di collegamento XML" [XLink]. Il lettore tenga presente che questa è attualmente ancora una bozza di lavoro, ed è perciò soggetta a future revisioni. Poiché il meccanismo di link del MathML è definito in termini della specifica di link dell'XML, lo stesso avviso vale anche per questo.
Un elemento MathML è identificato come link dalla presenza
dell'attributo xlink:href
. Per usare l'attributo
xlink:href
è inoltre necessario dichiarare lo
spazio di nomi appropriato. Perciò un tipico link MathML
può avere quest'aspetto:
<mrow xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="sample.xml"> ... </mrow>
Il MathML prevede che quasi tutti gli elementi possano essere usati
come elementi di link dell'XML. Gli unici elementi che non possono
essere usati come elementi di link sono quelli come l'elemento
sep
, che esiste principalmente per eliminare
l'ambiguità in altri costrutti MathML e che in generale non
corrisponde a nessuna parte di una visualizzazione tipica. La lista
completa degli elementi che fanno eccezione e non possono essere usati
come elementi di link è data nella seguente tabella.
mprescripts |
none |
sep |
malignmark |
maligngroup |
Si noti che anche le specifiche dei collegamenti in XML [XLink] e del linguaggio dei puntatori in XML [XPointer] definiscono come mettere un link all'interno di un'espressione MathML. Si tenga presente, comunque, che tali link possono o meno essere interpretati correttamente nel software attuale.
L'elemento IMG
non ha un equivalente in MathML. La
decisione di omettere un meccanismo generale per l'inclusione delle
immagini nel MathML è stata basata su diversi
fattori. Comunque, la ragione principale per non aver fornito un modo
per includere immagini è che il MathML deve rendere la
struttura notazionale e il contenuto matematico che codifica
facilmente disponibile agli elaboratori, mentre le informazioni
contenute in immagini sono disponibili solo ad un lettore umano che
guarda una loro rappresentazione visuale. Perciò, ad esempio,
nel paradigma MathML, sarebbe preferibile introdurre nuovi glifi
tramite l'elemento mglyph
che come minimo li identifica
come glifi, piuttosto che includerli semplicemente come immagini.
Infine, a prescindere dall'introduzione di nuovi glifi, molte situazioni dove si potrebbe voler usare un'immagine sono quelle dove si devono rappresentare diagrammi etichettati. Ad esempio, i diagrammi nodo, i diagrammi di Venn, i diagrammi di Dynkin, i diagrammi di Feynman e complicati diagrammi commutativi cadono tutti in questa categoria. Come al solito, il loro contenuto sarebbe codificato meglio tramite una combinazione di grafici strutturati e marcatura MathML. A causa della generalità della costruzione di `diagrammi etichettati', la definizione di un linguaggio di marcatura per codificare tali costruzioni esula dal campo dell'attuale attività nel campo della matematica del W3C. (Si veda http://www.w3.org/Graphics per ulteriore attività del W3C in questo campo.)
Sempre più informazioni sono generate, elaborate e visualizzate da strumenti software. La crescita esponenziale della rete sta esaurendo lo sviluppo di sistemi avanzati per la ricerca, la suddivisione in categorie e l'interconnessione automatica delle informazioni. Perciò, anche se il MathML può essere scritto a mano e letto dalla gente, il futuro del MathML è legato anche all'abilità di elaborarlo con strumenti software.
Ci sono molti tipi diversi di programmi di scrittura, traduttori, elaboratori e riproduttori MathML. Ciò significa che supportare il MathML varia ampiamente da un'applicazione all'altra. Per esempio, i problemi che sorgono in un analizzatore di convalida MathML-compatibile sono molto diversi da quelli per un programma per la scrittura di equazioni MathML-compatibile.
In questa sezione sono date linee guida per descrivere tipi diversi di supporto MathML e per quantificare l'estensione del supporto MathML in una data applicazione. Sviluppatori, utenti e revisori sono incoraggiati ad usare queste linee guida nel caratterizzare i prodotti. L'intenzione dietro queste linee guida è di facilitare il riuso e l'interoperabilità tra applicazioni MathML caratterizzando accuratamente le loro capacità in termini quantificabili.
Un'espressione MathML valida è un costrutto XML determinato dalla DTD del MathML insieme con i requisiti addizionali dati nelle specifiche dei documenti MathML.
Definiamo un `elaboratore MathML' qualunque applicazione che può accettare, produrre o `elaborare' un'espressione MathML valida. Un esempio di un'applicazione che può elaborare un'espressione MathML potrebbe essere un programma di scrittura che scrive un nuovo file anche se non sono state fatte modifiche.
Specifichiamo tre forme di compatibiltà MathML:
Oltre queste definizioni, le specifiche MathML non fanno richieste particolari ai singoli elaboratori. Al fine di guidare gli sviluppatori, le specifiche MathML comprendono materiale che contiene consigli; per esempio, si suggeriscono regole di visualizzazione nel Capitolo 3 [Marcatura di presentazione]. Comunque, in generale, gli sviluppatori hanno ampia scelta di interpretare qualunque tipo di implementazione MathML che sia significativa per la loro particolare applicazione.
Per chiarire la differenza tra compatibilità ed interpretazione di ciò che è significativo, consideriamo alcuni esempi:
Come mostra l'esempio precedente, per essere utile, il concetto di compatibilità MathML coinvolge spesso un giudizio su quali parti del linguaggio siano implementate in modo significativo, rispetto alle parti che sono semplicemente elaborate in un modo tecnicamente corretto rispetto alle definizioni di compatibilità. Questo richiede alcuni meccanismi per dare una definizione quantitativa su quali parti del MathML siano implementate in modo significativo da una data applicazione. A questo fine, il gruppo di lavoro per la Matematica del W3C ha fornito una serie di espressioni MathML di prova a http://www.w3.org/Math/testsuite.
La serie di prova consiste in un gran numero di espressioni MathML divise per categoria di marcatura e per l'elemento MathML dominante che si sta testando. L'esistenza di questa serie di prova rende possibile, per esempio, caratterizzare quantitativamente l'ipotetica interfaccia di computer algebra rammentata sopra dicendo che è un elaboratore compatibile in entrata con il MathML che implementa in modo significativo la marcatura di contenuto MathML, comprese tutte le espressioni date sotto http://www.w3.org/Math/testsuite/tests/4.
Gli sviluppatori che scelgono di non implementare parti delle specifiche MathML in modo significativo sono incoraggiati ad elencare le parti che hanno lasciato fuori facendo riferimento a specifiche categorie nella serie di prova.
Per elaboratori compatibili in uscita con il MathML, c'è anche un validatore MathML in rete a http://www.w3.org/Math/validator. Sviluppatori di elaboratori compatibili in uscita con il MathML sono incoraggiati a verificare i loro dati in uscita con questo validatore.
Clienti di applicazioni MathML che vogliono verificare le dichiarazioni riguardo a quali parti delle specifiche MathML sono implementate da un'applicazione sono incoraggiati ad usare le serie di prova come parte dei loro processi di decisione.
Il MathML 2.0 contiene vari costrutti del MathML 1.x che ora sono disapprovati. Chiariamo ora la relazione tra caratteristiche disapprovate e compatibilità con il MathML 2.0.
Se un'applicazione compatibile in entrata con il MathML riceve dati
in ingresso che contengono uno o più elementi con un numero o
un tipo illegale di attributi o di schemi figli, dovrebbe ugualmente
tentare di riprodurre tutti i dati in ingresso in un modo
comprensibile, ovvero riprodurre normalmente le parti valide dei dati
in ingresso e presentare messaggi di errore (riprodotti come se
inclusi in un elemento merror
) al posto delle espressioni
non valide.
Applicazioni compatibili in uscita con il MathML come programmi di
scrittura e traduttori possono scegliere di generare espressioni
merror
per segnalare errori nei loro dati in
ingresso. Questo è generalmente preferibile a generare valido,
ma probabilmente errato, MathML.
Gli attributi MathML descritti nelle specifiche MathML sono necessari per la marcatura di presentazione e di contenuto. Idealmente gli attributi MathML dovrebbero essere un elenco espandibile, in modo che gli utenti possano aggiungere attributi specifici per riproduttori specifici. Comunque, questo non può essere fatto entro i confini di una singola DTD XML. Anche se può essere fatto usando estensioni del DTD standard, alcuni autori vorranno usare attributi non standard per avvantaggiarsi di capacità specifiche del riproduttore rimanendo strettamente in compatibilità con la DTD standard.
Per permettere questo, le specifiche MathML 1.0 permettevano
l'attributo other
su tutti gli elementi, per usarlo come
un gancio per passare informazioni specifiche del riproduttore. In
particolare, era inteso come gancio per passare informazioni ai
riproduttori audio, ai sistemi di computer algebra e per la ricerca di
sottostringhe in meccanismi futuri di macro/estensioni. Il motivo di
questo approccio al problema era storico, considerando il PostScript,
per esempio, dove si usano ampiamente i commenti per passare
informazioni che non fanno parte del PostScript.
Nel frattempo, comunque, lo sviluppo di un meccanismo generale
degli spazi di nomi XML ha reso obsoleto l'uso dell'attributo
other
. Nel MathML 2.0 l'attributo other
è disapprovato in
favore dell'uso dei prefissi degli spazi di nomi per identificare
attributi non-MathML.
Ad esempio, nel MathML 1.0 si raccomandava che se si usavano
informazioni aggiuntive in un'implementazione specifica del
riproduttore per l'elemento maction
(Sezione 3.6.1 [Associare un'azione
ad una sottoespressione (maction
)]), quelle
informazioni dovevano essere passate usando l'attributo
other
:
<maction actiontype="highlight" other="color='#ff0000'"> expression </maction>
Nel MathML 2.0 si userebbe l'attributo color
da un
altro spazio di nomi:
<body xmlns:my="http://www.myrenderer.com/MathML/extensions"> ... <maction actiontype="highlight" my:color="#ff0000"> expression </maction> ... </body>
Si noti che l'intento di permettere attributi non standard non è quello di incoraggiare gli sviluppatori di software ad usarlo come una via d'uscita per aggirare le convenzioni di base della marcatura del MathML. Confidiamo che sia gli autori che le applicazioni useranno gli attributi non standard con giudizio.
Se il MathML deve rimanere utile in futuro, è giusto aspettarsi che il MathML avrà bisogno di essere esteso e rivisto in vari modi. Alcune di queste estensioni possono essere facilmente previste; per esempio, come va avanti il lavoro sulle estensioni di comportamento ai CSS, il MathML probabilmente avrà bisogno di essere esteso allo stesso modo.
Ugualmente, ci sono vari tipi di funzionalità che sono candidati piuttosto ovvi per estensioni future del MathML. Questi includono le macro, i fogli di stile, e forse una facilitazione generale per `diagrammi etichettati'. Comunque, senza dubbio ci saranno altre estensioni desiderabili al MathML che emergeranno solo quando il MathML sarà ampiamente usato. Per queste estensioni, il gruppo di lavoro per la Matematica del W3C conta sull'architettura estensibile dell'XML e sul buon senso della grande comunità Web.
Lo sviluppo di meccanismi come i fogli di stile per l'XML fa parte dell'attività XML in corso del Consorzio per il Web. Sia l'XSL che i CSS stanno cercando di incorporare maggior supporto per la matematica.
In particolare, le trasformazioni XSL [XSLT] probabilmente avranno un grande impatto sullo sviluppo futuro del MathML. Le macro hanno tradizionalmente contribuito largamente all'usabilità e all'efficacia delle codifiche matematiche. Chiaramente c'è richiesta di ulteriori applicazioni di sviluppo dell'XSLT adattate specificamente al MathML.
Alcuni possibili usi delle capacità delle macro per il MathML comprendono:
<msubsup>
come `derivata
seconda rispetto ad x di f'.
L'insieme di elementi ed attributi definiti nelle specifiche MathML sono necessari per riprodurre le comuni espressioni matematiche. Si riconosce che non tutta la notazione matematica è coperta da questo insieme di elementi, che si inventano continuamente nuove notazioni e che tra i matematici alcune sottocomunità spesso hanno notazioni specializzate; e inoltre che l'estensione esplicita di uno standard è un processo necessariamente lento e conservativo. Questo implica che lo standard MathML non potrà mai coprire esplicitamente tutte le forme di presentazione usate da ogni sottocomunità di scrittori e lettori di matematica, tantomeno potrà codificare tutto il contenuto matematico.
Per agevolare l'uso del MathML da parte del pubblico più ampio possibile, e per rendere possibile la sua rapida evoluzione in modo da avere più forme notazionali e più contenuto matematico (magari eventualmente coperto da estensioni esplicite dello standard), l'insieme di tag e di attributi è espandibile, nel senso descritto in questa sezione.
Il MathML è descritto da una DTD XML, che necessariamente limita gli elementi e gli attributi a quelli che occorrono nella DTD. I riproduttori che desiderano accettare elementi o attributi non standard e gli autori che desiderano includerli nei documenti dovrebbero accettare o produrre documenti conformi ad una DTD XML estesa in modo appropriato che abbia la DTD standard del MathML come sottoinsieme.
Si permette, ma non si richiede, che i riproduttori conformi al
MathML accettino elementi e attributi non standard e che li
riproducano in qualunque modo. Se un riproduttore non accetta alcuni o
tutti i tag non standard, è incoraggiato o a gestirli come
errori come descritto in precedenza per elementi con il numero
sbagliato di argomenti, o a presentare i loro argomenti come se
fossero argomenti di un elemento mrow
, in ogni caso
presentando tutte le parti standard dei dati in entrata nel modo
normale.
Descrizione sommaria: Linguaggio di
Marcatura Matematica (MathML) Versione 2.0
Precedente: 6 Caratteri, entità e
font
Successivo: 8 Modello a oggetti dei
documenti per il MathML