Newsgroup: it.comp.java
Titolo: database XML

Ciao.
Vorrei inserire in una mia applicazione un piccolo database in formato
XML, fatto + o - così :
<?xml version = '1.0'?>
<!DOCTYPE miodb [
<!ELEMENT miodb (ROW)*>
<!ELEMENT ROW (CODICE, DESCRIZIONE)>
<!ATTLIST ROW num CDATA #REQUIRED>
<!ELEMENT CODICE (#PCDATA)>
<!ELEMENT DESCRIZIONE (#PCDATA)>
]>
<miodb>
<ROW num="1">
<CODICE>01</CODICE>
<DESCRIZIONE>uno</DESCRIZIONE>
</ROW>
<ROW num="2">
<CODICE>02</CODICE>
<DESCRIZIONE>due</DESCRIZIONE>
</ROW>
<ROW num="3">
<CODICE>03</CODICE>
<DESCRIZIONE>tre</DESCRIZIONE>
</ROW>
</miodb>
Vorrei avere una libreria Java che implementa una seek su questo
database, cioè che mi ritorni le righe in cui un campo è uguale ad un
certo valore, possibilmente con performances accettabili ma senza
mangiarmi tutta la memoria. Siccome non dispongo delle risorse per
scrivermela io volevo chiedervi se... ehm... esiste qualcosa di precotto
in giro, va bene anche se scritto da voi...
Ciao, Cris
-- 
Cristian Veronesi ><((((º> 
http://www.crpa.it
Haleway sheyaamod! ("Speriamo che tenga", pare che abbia
esclamato l'Eterno contemplando il mondo appena creato)

mangiarmi tutta la memoria.
Ti serve un parser XML, il problema e' capire quale :-) - dipende dalle
dimensioni del documento che devi analizzare e dalle prestazioni che ti
servono.
Se ne cerchi uno molto compatto, prova a dare un'occhiata a questo:
http://www.gibaradunn.srac.org/tiny/index.shtml
(open source).
Tienici informati perche' mi interessa.

 Tienici informati perche' mi interessa.
OK, se ho delle novità vi farò sapere.



LOL benvenuto. E' circa un mese che sto cercando il modo migliore di rispondere 
alla tua domanda.
Molto dipende dal livello di generalita' che vuoi, dalle prestazioni, dal 
sizing del documento risultante e da considerazioni di "system integration".
Il modo "ufficiale" per localizzare univocamente frammenti di XML e' XPath, che 
e' usato in XSL, XLink e XPointer esattamente a riguardo.
Xpath ha un meccanismo di matching relativamente poco potente, ma adatto a 
molte situazioni. Un buon tutorial iniziale e' a 
http://www.javacommerce.com/tutorial/xml/overview.html
XQL e' un vero e proprio query language, ma non e' "ufficiale" W3C. Ci sono 
anche cinque o sei linguaggi di ricerca in proposito, e vari prodotti 
commerciali all'uopo - ad esempio Tamino, o l'ex-ObjectStore.
Il fatto e' che ancora *non* c'e' un analogo di SQL (qualcosa di standard e 
ragionevolmente potente) per XML.
Un buon paper teorico al riguardo e' "Querying XML data" di Deutsch et. al, su 
un'IEEE transaction se non ricordo male. Ho il postscript se ti serve. Io ho 
speso buona parte del mese di cui sopra a cavar fuori proprieta' generali del 
linguaggio di query che volevo che poi ho ritrovato - con gran consumo di 
fegato - pari pari li'. :)
C'e' anche una survey interessante sui prodotti disponibili che ho da qualche 
parte sull'hd, ma non trovo al momento :(
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

"ufficioso" chiamato XQL (
http://www.ibiblio.org/xql/
). Quindi quello
Hmm.. ne avevo sentito accennare. Tutto quello che gira attorno all'XML
e' in movimento, ed e' difficile restare aggiornati :-)
C'e' qualcosa che mi sfugge pero': come e' possibile confrontare un DBMS
con un DB basato su un documento XML, che supponiamo memorizzato su
disco in un file di testo.
Voglio dire, ci saranno dei limiti in termini di efficienza: gli indici
chi li gestisce? E come la mettiamo con gli aggiornamenti? Per cambiare
il valore di un tag (=aggiornare il campo di un record), deve essere
riscritto tutto il file? Non ci sono grossi problemi di integrita' dei
dati?
Se qualcuno puo' illuminarmi su queste questioni brevemente, gliene
sarei grato, visto che non ho molta voglia di inoltrarmi nell'oceano di
informazioni sull'XML :)

 ragionevolmente potente) per XML.
Si, ma ho scoperto che al W3C ci stanno lavorando. Non ho avuto tempo di
leggermi tutta la documentazione ma tra le "Experiences and Exemplars"
di questo fantomatico XML Query Language
(
http://www.w3.org/1999/09/ql/docs/xquery.html
) è citata una certa Mary
Fernandez degli AT&T Labs, la quale nel suo sito
http://www.research.att.com/~mff/
 propone un linguaggio di ricerca
chiamato XML-QL corredato di API Java scaricabili presso
http://www.research.att.com/sw/tools/xmlql
. A naso mi viene da dire che
se e quando il W3C proporrà uno standard sarà più simile a questo che a
XQL. Adesso mi scarico le API Java e me le guardo.


 dati?
A mio parere XML può sostituire o affiancare un DBMS solo in alcuni casi
specifici. Ovviamente bisogna tenere conto del volume delle informazioni
da memorizzare ma anche della loro natura intrinseca. Io in realtà
pensavo ad un evoluzione dei file *.properties, dei file di risorse
facilmente accessibili e modificabili che volevo tenere fuori dal DBMS
in quanto strettamente legati all'applicazione. Per quanto riguarda
l'efficienza, la libreria che ho provato ieri ci pensa lei a indicizzare
i file al momento della loro apertura. Ovviamente per grossi volumi di
dati XML rimane sconsigliabile. Anche l'integrità costituisce un
problema, in quanto eventuali errori devono essere gestiti a runtime.


XML-QL
Si', il board e' composto dagli stessi tizi dell'action Inria che compaiono 
negli articoli di cui sopra. Al momento non ho trovato granche' supporto 
operativo, e inoltre qui uso XSchema, e non DTD; per questo ho scelto, al 
momento, XPath - dato che comunque per quel che devo fare la potenza espressiva 
pare sufficiente, e stiamo costruendo un interessante semantica operazionale 
per valutare espressioni Xpath. 
Se riesci, fammi sapere come va con XML-QL, comunque, dato che la cosa e' 
interessante. Ogni tanto c'e' qualche commento in proposito anche su 
comp.text.xml - ma in genere le domande li' sono meno sofisticate.


facilmente accessibili e modificabili che volevo tenere fuori dal DBMS
Gia', un file XML mi sembra molto meglio per memorizzare le impostazioni
(quasi un ritorno ai file .ini con le varie [sezioni]? :-)
Non vorrei pero' che per gestire una ventina di "record" occorra
allegare 2-300K di librerie per il parsing, l'aggiornamento, e il query
dei documenti XML.

 pare sufficiente
Usate delle API precotte oppure le avete scritte voi? Nel secondo caso
immagino non siano di pubblico dominio, vero? :)



Se quello che devi fare e' usare XPath per estrarre parti di XML da file, no 
problem: il motore XSL di Apache funziona, e bene, e ce ne sono vari altri in 
giro (vedi w3c)
Fatto e' che noi stiamo usando sources eterogenee, e qui - ahime' - se do 
l'implementazione a qualcuno vado in galera per trent'anni per violazione di 
copyright, se pure sopravvivo. :)


 copyright, se pure sopravvivo. :)
Certo, capisco benissimo... diciamo che uno ce prova :)


query?¨
XSL e' un linguaggio di "trasformazione", da un documento XML sorgente ad un 
documento XML destinazione, basato su matching di parti della sorgente e regole 
di trasformazione. Per individuare la porzione di sorgente a cui una certa 
regola si applica, si usa XPath (che, anzi, e' stato inventato apposta ;-).


 regola si applica, si usa XPath (che, anzi, e' stato inventato apposta ;-).
Ma si possono trasformare solo i tag o anche i dati? Perchè io, in
questo momento, dovrei scrivere una classettina che, dato un certo
codice (composto da più tag), torni un'altro codice (anch'esso composto
da più tag), e pensavo di esprimere la relazione tra le codifiche
attraverso X*L, soltanto che sto ancora pensando come fare. E' possibile
scrivere in un file XML la prima codifica, un un file XSL le
corrispondenze tra prima e seconda codifica e poi chiedere al parser di
trasformarmi soltanto la parte di documento 1 corrispondente ad un certo
codice applicando le regole scritte nel file XSL?


codice applicando le regole scritte nel file XSL?
Bingo. :) La parte di XSL che si occupa principalmente di tag e' XSLT - ma con 
XSL - citando dal working draft al W3C - "In constructing the result tree, the 
source tree can be filtered and reordered, and arbitrary structure and 
generated content can be added".
Quanto sia piu'/meno facile rispetto ad una soluzione piu' tradizionale, non ho 
ancora sufficiente esperienza per valutarlo con certezza. Il vantaggio 
principale e' un po' lo stesso che hai usando i CSS per la grafica HTML - la 
trasformazione e' un "oggetto" a se', sganciato dal codice (java, ad esempio) e 
potenzialmente riusabile. E in ogni caso, dopo il primo impatto, non mi pare 
punto difficile. :)
Tieni presente che XSL/XSLT comunque e' ancora allo stadio working draft - non 
e' probabile cambi granche' ma non e' ancora una recommendation.


 e' probabile cambi granche' ma non e' ancora una recommendation.
OK, ho comunque deciso di buttarmi su Xalan... e mi sono incagliato
subito!
Ho provato a cambiare una riga di codice dall'esempio
SimpleTransform.java per provare a memorizzare i risultati in un Node
anzichè sbatterli sullo standard out e mi da sempre questo errore:
XSL Error: Cannot use a DTMLiaison for an output DOM node... pass a
org.apache.x
alan.xpath.xdom.XercesLiaison instead!
XSL Error: SAX Exception
org.apache.xalan.xslt.XSLProcessorException: 
        at
org.apache.xalan.xslt.XSLTEngineImpl.error(XSLTEngineImpl.java:1756)
        at
org.apache.xalan.xslt.XSLTEngineImpl.error(XSLTEngineImpl.java:1648)
        at
org.apache.xalan.xslt.StylesheetRoot.process(StylesheetRoot.java:396)
        at
org.apache.xalan.xslt.XSLTEngineImpl.process(XSLTEngineImpl.java:679)
        at Test.main(Test.java:26)
Allego il codice: vista la tua esperienza il mio errore madornale ti
salterà subito all'occhio... io non ci salto più fuori.
import org.xml.sax.SAXException;
import org.apache.xalan.xslt.XSLTProcessorFactory;
import org.apache.xalan.xslt.XSLTInputSource;
import org.apache.xalan.xslt.XSLTResultTarget;
import org.apache.xalan.xslt.XSLTProcessor;
import org.apache.xalan.xpath.xdom.XercesLiaison ;
/**
 * Simple sample code to show how to run the XSL processor
 * from the API.
 */
public class Test
{
	public static void main(String[] args)
    throws java.io.IOException,
           java.net.MalformedURLException,
           org.xml.sax.SAXException
	{
    // Have the XSLTProcessorFactory obtain a interface to a
    // new XSLTProcessor object.
    XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
    // Have the XSLTProcessor processor object transform "foo.xml" to
    // System.out, using the XSLT instructions found in "foo.xsl".
    processor.process(new XSLTInputSource(args[0]),
                      new XSLTInputSource(args[1]),
                      // new XSLTResultTarget(System.out));
                      new
XSLTResultTarget(((XercesLiaison)processor.getXMLProcessorLiaison()).createDocument()))
;


subito!
Purtroppo, per ragioni di prestazioni, io mi sono sempre limitato ad usare SAX 
- quindi non ho idea di cosa stia succedendo. :(


 >
Già che siamo in tema; 
è da un mese che cerco di estrarre i dati da un file XML; ho letto un
po' di tutorial ma non
ci ho capito granchè...
In pratica, ho un file di testo in questa forma:
	<datoPadre>
		<datoFiglio> Prova </datoFiglio>
		<datoFiglio2> XML </datoFiglio2>
	</datoPadre>
e devo cercare di estrarre datoFiglio ( ovvero la string "Prova" ) e
datoFiglio2 ( "XML" )
Avete qualche idea o un link dove trovare tutorial esaustivi?
Ah già, naturalmente il tutto gira in Java.
Grazie.
Ciao,
	Roberto Venturetti

:

Ci sono vari modi. Quello piu' semplice e intuitivo e' fare il parsing del 
documento XML, fornendo al parser callbacks dove risponde a determinati eventi 
("ho trovato un elemento che si chiama datoFiglio, che ci vuoi fare?").
Quello che il parser offre di default - ed e' questo il vantaggio di  XML - e' 
la verifica (well-formness) e validazione (rispetto ad un DTD/XSchema, se 
esiste) automatica, senza che tu debba fare nulla. 
Il tutto, a 
java.sun.com
 (JAXP - che e' un leggero wrapper su un set di parsers 
esistenti, piu' l'implementazione di un parser SAX di Apache) e appunto 
www.apache.org
 (xceres) - che e' lo stesso parser ma piu' aggiornato.
Entrambi supportano anche i namespace. Se invece vuoi usare XPath, usi XAlan - 
anche se recentemente le API sono state rivoluzionate.


 anche se recentemente le API sono state rivoluzionate.
Ok, grazie mille.
Ciao,
	Roberto Venturetti

 datoFiglio2 ( "XML" )
1. crei un'istanza del DOM parser :
DOMParser parser = new DOMParser() ;          
2. parsi il file di testo :
parser.parse(...) ;  
3. ottieni dal parser un'istanza del documento:
Document doc = parser.getDocument() ;         
4. ottieni una nodelist di tutti gli elementi che si chiamano
"datoFiglio" :
 
NodeList nlist = resultDocument.getElementsByTagName("datoFiglio") ;
5. presupponendo che la nodelist contenga un solo elemento, lavori sul
nodo di indice 0; di questo ottieni un'istanza del suo primo (e unico in
questo caso) figlio (cioè il nodo che rappresente la stringa "Prova");
di questo nodo ottieni il valore :
String datoFiglio = item(0).getFirstChild().getNodeValue() 
6. ripeti i punti 4 e 5 con "nodoPadre"
Questo è anche tutto ciò che so fare con XML... può darsi che sia
concettualmente sbagliato, ma ti posso assicurare che funziona. 
