[PLUTO-Journal] Alcune riflessioni (era A volte ritornano)

Marcello Seri linuxml.ms a gmail.com
Mer 19 Gen 2005 15:48:54 CET


On Tue, 18 Jan 2005 22:52:10 +0100, Marco Marongiu <bronto a tiscali.com> wrote:
> nicolafragale a libero.it wrote:
> > Tuttavia non abbiamo mai osservato con chiarezza che questo software dovrebbe
> > essere utilizzato principalmente da due distinte categorie di utenti.
> > Gli articolisti, ai quali deve essere fornito l'elenco dei tag e le regole per
> > utilizzarli in modo corretto.
> > Gli impaginatori, che ricevuti gli articoli li sottopongono ai vari fogli di
> > stile e generano il formato necessario (html, pdf, ...)
> 
> In realta` gli impaginatori danno solo le specifiche su come vogliono le
> pagine, e a noi spetta di implementarle con i fogli di stile. Una volta
> definiti quelli basta fornire agli impaginatori lo strumentino per
> comporre il journal e dirgli di schiacciare il bottone :-)
> 
> Senza scherzi, per come la vedo io una volta fornite le specifiche gli
> impaginatori devono sapere essenzialmente:
> 
> * come assemblare i vari articoli dentro un XML unico
Questo si fa con un XSL, è molto più semplice di quanto sembra se si
hanno nella stessa carella tutti gli articoli in xml e ancora più
semlìplice se si crea anche un indice in xml

> * come eseguire la procedura che spacchetta quel XML in tutti i formati
> necessari.

questo è il punto da discutere bene...

> > Il cuore di tutto ciò sono i tag, che bene o male abbiamo. Tuttavia occorre
> > documentarli, l'articolista _dovendo_ utilizzarli _deve_ averne un elenco con
> > significato e sintassi, e da qui anche se in modo diverso ritorna la necessità
> > di una pagina web. Trattandosi *solo* della sintassi dei tag da utilizzare, si
> > potrebbe inserire nella pagina del Journal dove si spiega come contribuire.
> 
> Sono quasi d'accordo, ma per la prima fase in cui ancora stiamo ancora
> "pastrocchiando" forse la via piu` breve e`:
> 
> * prendere alcuni articoli gia` pubblicati sul PJ
> * convertirli da HTML a XPJ
> * provare a ricomporre da essi un(-a parte di) numero del PJ
> * imparare da questi processo cosa va, cosa non va, pratiche e procedure
> * modificare cio` che va modificato
> * reiterare dal secondo punto fino al conseguimento di un risultato
> soddisfacente

Sono daccordo ma prima c'è comunque da stabilire quali teconologie
utilizzare o al più selezionarne 2 e non di più da contfrontare per
scegliere con maggiore sicurezza
 
> > Visto il problema sotto questa ottica, si potrebbe partire abbastanza
> > velocemente con una "sperimentazione". Abbiamo il pacchetto 0.1 creato da Marco
> > con tag, fogli di stile e filtro da xml a html, questo è più o meno quello che
> > deve utilizzare l'impaginatore e che l'articolista non deve conoscere.
> 
> Non credo che quel materiale sia gia` utilizzabile, perche':
> 
> * il mio foglio di stile faceva la conversione in un HTML ordinato e
> pulito (forse :-) ma quel formato non era stato discusso: era una prova
> mia, per vedere che la cosa funzionava; insomma: il Journal che verra`
> probabilmente non assomigliera` neanche lontanamente a quelle pagine;

E chi lo sa ;P

> * l'articolista, allo stato attuale, _dovrebbe_ conoscere i tag, ma non
> ci possiamo permettere questo lusso :-) credo che la via piu` breve sia
> quella descritta sopra: riconvertiamo (eventualmente a manella) alcuni
> articoli pubblicati in XPJ e lavoriamo su quelli fino al conseguimento
> di un prototipo funzionante.

Questo è un punto su cui possiamo lavorare bene solo dopo aver deciso
come implementare XPJ. Sinceramente a me piace come è stato
implementato Python Italian Journal (www.pyj.it)

> > E' necessario creare la documentazione minima perchè il pacchetto possa essere
> > usato. Ora non ricordo la procedura da seguire, ma qualunque essa sia, la
> > dobbiamo formalizzare (software da installare sui server: AxKit, se non ricordo
> [...]
> 
> AxKit sarebbe servito per poter avere una installazione "live" di XPJ su
> cui fare tutte le prove del caso (p.e.: poter provare online i diversi
> fogli di stile durante lo sviluppo); se si vuole utilizzare AxKit anche
> per la pubblicazione bisogna tenere conto che tutte le pagine del
> journal sarebbero create in dinamico e che mod_perl ciuccerebbe un bel
> po` di RAM: non se ne uscirebbe vivi senza mettere davanti ad AxKit
> (sulla stessa macchina) un reverse proxy cache/accelerator.

mi sa che è più semplice lasciare l'impaginazione al browser
attraverso XSLT allora

> > Avendo la documentazine dei tag io potrei iniziare ad abbozzare un prototipo di
> > editor.
> 
> la documentazione dei tag era quel documento in formato XPJ che avevo
> mandato, con la sua traduzione in HTML: era una vera e propria live demo
> del formato.

Puoi mandarmelo in pvt che è andato perso con il mio defunto disco fisso??

-- 
MasteRNeT - Membro di Majalinux, MajaGlug e GLM
Linux Registered User #310524
Debian, Slackware, Gentoo, SUSE, Fedora e Mandrake Happy Power User



Maggiori informazioni sulla lista pluto-journal