XML per Office aperto, per sempre

Lo promette Microsoft, che risponde così alle sollecitazioni dell'Unione Europea. Interoperabilità e licenza priva di royalty nei formati di documenti XML prodotti con Office


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”.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Anonimo scrive:
    Re: 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%2F
  • Anonimo scrive:
    Re: 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!
  • Anonimo scrive:
    Re: 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!!!
  • flyonthenet scrive:
    Re: 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
  • Anonimo scrive:
    BENE! 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.....
    • Anonimo scrive:
      Re: 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 opera
    • Anonimo scrive:
      Re: 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.
  • Anonimo scrive:
    Re: 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)Ecio
  • Anonimo scrive:
    Re: 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...Ecio
  • Anonimo scrive:
    Re: 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.
  • JackMauro scrive:
    Re: 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....Mauro
  • Anonimo scrive:
    Re: 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?
  • Anonimo scrive:
    Re: 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...)Ecio
    • Anonimo scrive:
      Re: 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.
    • Anonimo scrive:
      Re: 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 paralizza
  • JackMauro scrive:
    Re: gzip, deflate
    Invece SI!e con gprs la differenza si vede!!!Mauro
  • pandavr scrive:
    Re: 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.50
  • Anonimo scrive:
    Re: 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..
  • Anonimo scrive:
    Re: 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ù.
  • JackMauro scrive:
    Re: 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...Mauro
  • carobeppe scrive:
    Distinguiamoci 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!
  • Anonimo scrive:
    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...).
Chiudi i commenti