Redmond (USA) – Nulla deve ostacolare la diffusione dei formati di documenti Office basati su XML: questa la strategia che Microsoft ha voluto confermare rispondendo alle sollecitazioni dell’Unione Europea. L’azienda ha infatti confermato che gli schemi XML dei propri formati saranno per sempre disponibili su licenza libera da qualsiasi royalty.
Non solo. Il big di Redmond ha anche assicurato che fornirà tutta la documentazione necessaria alla realizzazione di software di terze parti che possano leggere il formato XML dei prodotti Office e che anzi ne incoraggerà la realizzazione. Non è d’altra parte inatteso l’interesse di altri produttori in questo senso visto che Sun Microsystems già da alcune settimane ha rivelato la propria intenzione di realizzare i filtri ad hoc per StarOffice e OpenOffice.
Ciò su cui Microsoft ha preferito non seguire le indicazioni dell’Unione riguarda invece la presentazione degli schemi XML ad un organo di standardizzazione esterno. L’azienda ha infatti preferito la via dello sviluppo interno delle specifiche spiegando di voler così mettere a frutto le proprie competenze in materia di mantenimento della retrocompatibilità.
Nelle prossime ore, già oggi in realtà, Microsoft dovrebbe rendere pubblica la lettera che contiene queste decisioni e che l’azienda ha trasmesso nei giorni scorsi alla Commissione Europea. Una lettera con cui il colosso del software ha voluto rispondere alle indicazioni emerse dal lavoro dell’Ufficio per l’interoperabilità della Commissione.
Il motivo essenziale dell’appello della Commissione per formati standard è quello di sempre, ovvero la necessità per le amministrazioni dei paesi membri di mantenere i propri database il più possibile accessibili ai diversi soggetti che nel tempo vi devono poter accedere nei diversi paesi.
“C’è un nuovo mondo che sta facendosi avanti – ha dichiarato a questo proposito Jean Paoli, che non è soltanto il responsabile dell’architettura XML in Microsoft ma è anche uno dei padri di XML 1.0 – i Contenuti sono posseduti dall’utente e non dal software. E questo è molto importante. Tutti i contenuti possono essere creati con Office e ora archiviati in sicurezza con l’XML, con la possibilità di interagire non solo con altre applicazioni desktop ma anche con software di back-end”.
-
gzip, deflate
queste 2 forme di compressione sono gia' supportate sia da mozzilla che da IE... io mi chiedo xke i provider non abilitano la compressione di default, o perche' non venga richiesta (sempre di default) dai browser che la supportano.Risparmieremmo tutti un sacco di banda (appunto 6 volte in meno su html,asp,php etc...).AnonimoDistinguiamoci sempre...
Quoto dall'articolo:Perché ciò avvenga, sia il client (in questo caso Opera) sia il server (quello che fornisce il servizio di connettività all'utente) devono supportare la tecnologia di SlipStream: al momento nessun provider italiano ne ha ancora annunciato pubblicamente il supporto.... te pareva che una volta tanto l'italia si distinguesse per essere quella più all'avanguardia... visto che siamo campioni nell'essere uno fra i paesi meno broadbandizzati d'europa almeno la banda stretta potrebbe essere migliorata!carobeppeRe: gzip, deflate
Perché i provider non le supportano? semplice... consuma CPU sul web server... ma anche se lo supportassero... gli utenti non se ne accorgerebbero!Questo è il mio sito:http://jack.logicalsystems.it/homepage/Secondo voi supporta le compressioni GZIP e/o Deflate?Si aprono scommesse...MauroJackMauroRe: gzip, deflate
> Secondo voi supporta le compressioni GZIP> e/o Deflate?NOse no sarebbe molto ma molto più lento.... la velocità sul web non nasce affatto dalla velocità di banda ma dalla velocità di risposta del server, ovvero, potenza di CPU, e qui GZIP e deflate fanno solo danni e nulla più.AnonimoRe: gzip, deflate
> la velocità sul web non nasce affatto dalla velocità di banda ma dalla velocità di risposta del server, ovvero, potenza di CPU, e qui GZIP e deflate fanno solo danni e nulla più.azz.. un genio..AnonimoRe: gzip, deflate
- Scritto da: Anonimo> > la velocità sul web non nasce> affatto dalla velocità di banda ma> dalla velocità di risposta del> server, ovvero, potenza di CPU, e qui GZIP e> deflate fanno solo danni e nulla più.> > azz.. un genio..Ed aggiungiamo che se si può salvare l'inventore del html con motivazioni storiche, altrettanto non si può fare con w3c per l'xml. Un grande passo avanti è indubbio: ma perchè utilizzare un linguaggio di markup che costringe a riscrivere il nome di un tag per chiuderlo? L'xml si poteva creare facendogli "consumare" quasi metà della banda. Inoltre a chi frega se con xml si può scrivere l'html? Non è forse vero che XHTML NON E' per nulla compatibile con HTML? Ah, ok sono le pagine scritte fino ad ora ad essere scritte male ;)Alle volte non li capisco... :(==================================Modificato dall'autore il 08/11/2004 7.57.50pandavrRe: gzip, deflate
Invece SI!e con gprs la differenza si vede!!!MauroJackMauroRe: gzip, deflate
> Ed aggiungiamo che se si può salvare> l'inventore del html con motivazioni> storiche, altrettanto non si può fare> con w3c per l'xml. Un grande passo avanti> è indubbio: ma perchè> utilizzare un linguaggio di markup che> costringe a riscrivere il nome di un tag per> chiuderlo? perche' cosi' il documento e' ben-formato e puo' essere processato da una macchina (cerca online i concetti di well-formed e machine-readable)> L'xml si poteva creare facendogli> "consumare" quasi metà della banda.> Inoltre a chi frega se con xml si può> scrivere l'html?A nessuno, infatti non e' nato per la visualizzazione ma per l'interscambio dei dati tra diverse applicazioni> Non è forse vero che> XHTML NON E' per nulla compatibile con HTML?No, basta che l'HTML sia scritto bene e diventa XHTML > Ah, ok sono le pagine scritte fino ad ora ad> essere scritte male ;)Esatto > Alle volte non li capisco... :(Infatti, e' meglio se lasci stare...E comunque l'XML puo' utilizzare anche trasferimenti binary, certo qche meccanismo tipo gzip forse proprio male non fa...PS Per quello che dice che il gzip non serve niente, prova a caricare questo http://packages.debian.org/testing/allpackagese invece questohttp://packages.debian.org/testing/allpackages.en.txt.gz(ok che la prima e' html e la seconda txt, ma le velocita' non son neanche paragonabili...)EcioAnonimoRe: gzip, deflate
- Scritto da: Anonimo> ....> PS Per quello che dice che il gzip non serve> niente, prova a caricare questo> packages.debian.org/testing/allpackages > e invece questo> packages.debian.org/testing/allpackages.en.txPresumo che intendesse nel caso di compressione 'on the fly' e non nel caso di un documento archiviato sul server in due versioni: compressa e non compressa. A questo punto bisogna vedere se è più veloce l'ISP a comprimere il pacchetto o la tua linea a trasferire il pacchetto non compresso. Ovviamente dipende tutto dalla velocità del server e, soprattutto, dalla velocità di collegamento. Chiaro che se sei collegato con una linea a 10 Mbps probabilmente farai prima a scaricare il pacchetto non compresso, mentre se ti colleghi con una velocità molto minore il discorso sarà diverso. Infatti Opera dichiara: "Su stessa ammissione di Opera Software, gli utenti di connessioni a larga banda (xDSL, cavo, satellite, ecc.) beneficeranno poco o nulla della tecnologia di SlipStream: dove questa può fare davvero la differenza, infatti, è sulle connessioni più lente, come quelle analogiche a 56 Kbps o quelle fornite oggi dalle reti cellulari (GSM, GPRS, EDGE, UMTS)."Una cosa però non mi torna... nel caso in cui la tecnologia potrebbe essere più utile, e cioè il collegamento tramite modem, mi risulta che la compressione dei dati si faccia ormai da anni e tra l'altro che venga effettuata via hardware dal modem, senza pesare quindi sul server.AnonimoRe: gzip, deflate
> PS Per quello che dice che il gzip non serve> niente, prova a caricare questo> packages.debian.org/testing/allpackages > e invece questo> packages.debian.org/testing/allpackages.en.tx> (ok che la prima e' html e la seconda txt,> ma le velocita' non son neanche> paragonabili...)ma chi ha mai detto che gzip come compressione in quanto tale non serve a niente, il fatto è che on the fly fa danni enormi, perché il problema spessissimo dei web server è il consumo di cpu... e li se abiliti gzip il sistema si paralizzaAnonimoRe: gzip, deflate
- Scritto da: JackMauro> Invece SI!> > e con gprs la differenza si vede!!!> > Mauroma sbaglio o nel gprs ci sono gia' i proxy degli operatori telefonici che comprimono (io sapevo le immagini) per ridurre la banda?AnonimoRe: gzip, deflate
Sbagli.... gli operatori telefonici proxano solo WAP... non il web...Io uso opera da nokia 6600 e IE/Firefox da pc sempre tramite gprs... e wind almeno non mi offre nessun proxy...Ho provato a mettermi su un proxy in ufficio che gzippi tutti i siti che visito ma ha problemi... invece il mio sito gzippato nativo non mi da nessun problema...Cmq su windows 2003 server la compressione funziona... mentre su 2000 server non ne voleva sapere... dava solo casini....MauroJackMauroRe: gzip, deflate
Anche io ho il 6600. Uso Opera per Symbian e sfrutto il proxy che mette a disposizione Opera. La differenza è notevole, soprattutto per il fatto che le immagini vengono ottimizzate per "entrare" nel display del telefonino. Se uso il collegamento col PC e Firefox (e quindi senza proxy) per vedere la stessa pagina ci metto almeno più del doppio.Se grosse pagine HTML venissero zippate io ne avrei grossi vantaggi visto il mio collegamento lento (GPRS). C'è poco da fare, il GPRS è troppo altalenante come performance, quindi anche il 50% di byte in meno sarebbero una manna dal cielo.AnonimoRe: gzip, deflate
> Presumo che intendesse nel caso di> compressione 'on the fly' e non nel caso di> un documento archiviato sul server in due> versioni: compressa e non compressa. A> questo punto bisogna vedere se è> più veloce l'ISP a comprimere il> pacchetto o la tua linea a trasferire il> pacchetto non compresso. Si questo e' vero, in caso di compressione on the fly i web server sarebbero caricati non poco. Ma l'idea di fare pagine gzippate non mi pare malaccio: con dei webserver abbastanza intelligenti la compressione potrebbe essere realizzata in anticipo sulle pagine statiche e invece in modalita' batch (oppure on demand + caching, tipo proxy) sulle pagine dinamiche> . Infatti Opera dichiara:> "Su stessa ammissione di Opera Software, gli> utenti di connessioni a larga banda (xDSL,> cavo, satellite, ecc.) beneficeranno poco o> nulla della tecnologia di SlipStream: dove> questa può fare davvero la> differenza, infatti, è sulle> connessioni più lente, > Una cosa però non mi torna... nel> caso in cui la tecnologia potrebbe essere> più utile, e cioè il> collegamento tramite modem, mi risulta che> la compressione dei dati si faccia ormai da> anni e tra l'altro che venga effettuata via> hardware dal modem, senza pesare quindi sul> server.Concordo con te, mi pare un po' una banfata quella della tecnologia + rivoluzionaria degli ultimi 20 anni...EcioAnonimoRe: gzip, deflate
Ok grazie x la precisazione, avevo letto male sui NG (non ho ne' wap ne' gprs quindi non ho mai approfondito)> Anche io ho il 6600. Uso Opera per Symbian e> sfrutto il proxy che mette a disposizione> Opera. La differenza è notevole,> soprattutto per il fatto che le immagini> vengono ottimizzate per "entrare" nel> display del telefonino. Se uso il> collegamento col PC e Firefox (e quindi> senza proxy) per vedere la stessa pagina ci> metto almeno più del doppio.c'e' da dire pero' che in certi contesti questo proxy-ing fa piu' danni che altro (pensa quando vuoi scaricare una galleria di immagini di modelle e il proxy te le ritorna compresse :D)EcioAnonimoBENE! Pensiamo anche al Digital Divide!
Finalmente qualcuno incomincia a pensare anche alle povere vittime del Digital Divide.Per me che navigo a 56k, navigare 6 volte più veloce mi sembrerebbe un miracolo! Ma funzionerà? Come si fa a comprimere ulteriormente un JPG?Stiamo a vedere e speriamo.....AnonimoRe: BENE! Pensiamo anche al Digital Divi
- Scritto da: Anonimo> Finalmente qualcuno incomincia a pensare> anche alle povere vittime del Digital> Divide.> > Per me che navigo a 56k, navigare 6 volte> più veloce mi sembrerebbe un> miracolo! Ma funzionerà? Come si fa a> comprimere ulteriormente un JPG?> > Stiamo a vedere e speriamo.....quei numeri si riferiscono solo a compressioni su html, scordati vantaggi su download binari o su jpegla banda te la può dare soltanto la centrale telecom, non certo operaAnonimoRe: BENE! Pensiamo anche al Digital Divide!
- Scritto da: Anonimo> Finalmente qualcuno incomincia a pensare> anche alle povere vittime del Digital> Divide.> > Per me che navigo a 56k, navigare 6 volte> più veloce mi sembrerebbe un> miracolo! Ma funzionerà? Come si fa a> comprimere ulteriormente un JPG?hai detto giusto e la risposta è...non si fa o cmq molto poco quel valore è dato su di una media tra testo immagini audio ecc ecc ed è cmq un valore molto largo di manica è chiaro che un miglioramente sicuramente c'è e per tutti quei posti non ragiungibili dallìadsl è sicuramente una svolta.AnonimoRe: gzip, deflate
> è indubbio: ma perchè> utilizzare un linguaggio di markup che> costringe a riscrivere il nome di un tag per> chiuderlo? Falso, in XML puoi chiudere un tag anche in questo modo:>L'xml si poteva creare facendogli> "consumare" quasi metà della banda.Se lavori con gli strumenti giusti riesci anche a creare file XHTML più compatti rispetto a HTML, rimuovendo tutti i caratteri tipo spazi multipli, tabulazioni e cr che vengono ignorati dal parser.> Non è forse vero che> XHTML NON E' per nulla compatibile con HTML?No, è il contrario.Ciao
flyonthenetRe: Distinguiamoci sempre...
- Scritto da: carobeppe> Quoto dall'articolo:> Perché ciò avvenga, sia il> client (in questo caso Opera) sia il server> (quello che fornisce il servizio di> connettività all'utente) devono> supportare la tecnologia di SlipStream: al> momento nessun provider italiano ne ha> ancora annunciato pubblicamente il supporto.> > ... te pareva che una volta tanto l'italia> si distinguesse per essere quella più> all'avanguardia... visto che siamo campioni> nell'essere uno fra i paesi meno> broadbandizzati d'europa almeno la banda> stretta potrebbe essere migliorata!Ma perchè parlate e non sapete? prima wind poi tin hanno annunciato il supporta a questa nuova tecnologia!!!AnonimoRe: BENE! Pensiamo anche al Digital Divi
> la banda te la può dare soltanto la> centrale telecom, non certo operasi è vero ma questo algoritmo di compressione totalmente riscritto anche se con valori minimi comprimerà anche binari e jpg con un incremento non indifferente infondo se dovevano indicare la sola compressione del testo quella avviene al 90% quindi avrebbero scritto molto più di 6x anche io sono scettico sul 6x ma anche se fosse un 3x effettivo sarebbe una bella cosa!AnonimoRe: gzip, deflate
- Scritto da: JackMauro> Perché i provider non le supportano?> semplice... consuma CPU sul web server... ma> anche se lo supportassero... gli utenti non> se ne accorgerebbero!> > Questo è il mio sito:> jack.logicalsystems.it/homepage /> > Secondo voi supporta le compressioni GZIP> e/o Deflate?> > Si aprono scommesse...c'è poco da scommettere........................................................http://www.pipeboost.com/GetReport.asp?URL=http%3A%2F%2Fjack.logicalsystems.it%2Fhomepage%2FAnonimoGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoGrazie per esserti iscritto alla nostra newsletterOops, la registrazione alla newsletter non è andata a buon fine. Riprova.Leggi gli altri commentiPubblicato il 8 nov 2004Ti potrebbe interessare