Ciao Alberto,

dando un'occhiata alla pagina degli elementi critici di traduzione mi
sento in obbligo di fare alcuni appunti.

Per quanto riguarda l'ambiguità nella traduzione degli attributi posso
smentirti in quanto l'algoritmo che avevo trovato io (e leggermente
modificato nella forma e non nella sostanza come vedrai nella tabella
che metterò on-line non appena avrò finito) non dovrebbe creare
ambiguità. Riportando infatti il tuo esempio

<!ELEMENT city (nome, stato)>
<!ATTLIST city 
	zipCode ID #REQUIRED 
	phonePrefix CDATA #FIXED "059"
	nome CDATA #IMPLIED>
<!ELEMENT nome (#PCDATA)>
<!ELEMENT stato (#PCDATA)> 

Il mio wrapper genera la struttura ODLi3

interface city 
( source semistrutured
?key attlist_zipCode )
{ 
	attribute string city_zipCode;
	const string city_phonePrefix="059";
	attribute string city_nome*;
	attribute string nome;
	attribute string stato;
}; 

E quindi non esiste più ambiguità.

Per quanto riguarda la mappatura di key e foreign key con la prof. e
Maurizio eravamo giunti all'idea di proporre la cosa al progettista non
ritenendo necessaria la codifica e soprattutto non essendo sicuri del
rispetto delle regole di integrità referenziale in un file XML. Questo
era stato fatto inserendo il carattere ? (anche se io preferivo un ???)
per terminare la mappatura.

Per quanto riguarda l'enumerated è stato fornito un algoritmo per la
traduzione nel costrutto enum di ODLi3. Quindi l'esempio che hai
riportato

<!ELEMENT city (nome, stato)>
<!ATTLIST city 
	phonePrefix (059|0536|0535) "059">
<!ELEMENT nome (#PCDATA)>
<!ELEMENT stato (#PCDATA)> 

Diventa

enum city_phonePrefix
{
	'059','0536','0535'
} 

interface city ( extent city )
{ 
	attribute city_phonePrefix city_phonePrefix;
	attribute string nome;
	attribute string stato;
}; 

Rimane sempre la non possibilità di tradurre in ODLi3 il valore di
default.

Per quanto riguarda gli elementi ANY basta tradurli come gli elementi
#PCDATA in quanto si tratta di un vincolo di XML che non influisce
assolutamente a livello di ODLi3

Infine per quanto riguarda gli elementi EMPTY io proporrei di non
tradurli in quanto in ODLi3 non portano informazione se non quella di
essere da "padre" per alcuni attributi. Quindi una traduzione del tipo

<!ELEMENT city (nome,stato) >
<!ELEMENT nome (#PCDATA)>
<!ELEMENT stato EMPTY>
<!ATTLIST stato code CDATA> 

interface city ( extent city )
{ 
	attribute string nome;
	attribute string stato_code*;
}; 

mi riporta tutte le informazioni che necessitano. Ad ogni modo questo
particolare argomento, a detta della prof., sarà discusso nella prossima
riunione di martedì in quanto ha detto che ne approfittiamo per
discutere la mia idea tra tutti gli interessati.

Adesso ti faccio una domanda: quale è il significato di extent che tu
metti dopo interface e quale è il criterio per il quale decidi che si
deve chiamare in quel modo???

-- 
      _
     //\
Bye,//--\ndrea
(http://www.aga.it/~andrea)