Un petit résumé du résumé de la décision l'AFNOR (elle) propose :
- une unique norme pour les format bureautique
- séparer OOXML (standard ECMA) en :
- une partie normalisable (core)
- une partie extensions pour la partie compatibilité des vieux word
Ils veulent faire ca de la manière suivante :
(1) on prends les commentaires et OOXM devient une Spécification technique (pas encore une norme)
(2) avec (1) == OOXML core revisé + ODF = norme bureautique
(3) : évolution de (2) uniquement gérée par ISO
avoir une unique norme pour les documents est nécessaire, sinon ce sera le bordel,
ensuite je lis la décision comme OOXML est pas si mauvais si on vire la partie compatibilité difficilement réalisable (par rapport au OOXML-Core plus facile), mais quand même avec des commentaires.
Ensuite l'intéressant dans la décision est le chemin proposé:
(1) OOXML != norme
(2) ODF et OOXML sont fusioné
(1) peut empécher un éditeur d'avoir une norme; mais laisse le processus ouvert pour (2)
(2) va produire (j'espére) un format qui n'est pas directement ni OOXML ni ODF, avec un effort nécessaire pour les éditeurs de logiciel d'avoir autre chose que son architecture interne dans un format XML (je pense que c'est valable pour OO et Microsoft Office (c) (r) (patent et co)).
[^] # Re: Décision AFNOR comique ?
Posté par ham . En réponse au journal L'AFNOR a dit non à l'OOXML, quid des autres votes ?. Évalué à 4.
- une unique norme pour les format bureautique
- séparer OOXML (standard ECMA) en :
- une partie normalisable (core)
- une partie extensions pour la partie compatibilité des vieux word
Ils veulent faire ca de la manière suivante :
(1) on prends les commentaires et OOXM devient une Spécification technique (pas encore une norme)
(2) avec (1) == OOXML core revisé + ODF = norme bureautique
(3) : évolution de (2) uniquement gérée par ISO
avoir une unique norme pour les documents est nécessaire, sinon ce sera le bordel,
ensuite je lis la décision comme OOXML est pas si mauvais si on vire la partie compatibilité difficilement réalisable (par rapport au OOXML-Core plus facile), mais quand même avec des commentaires.
Ensuite l'intéressant dans la décision est le chemin proposé:
(1) OOXML != norme
(2) ODF et OOXML sont fusioné
(1) peut empécher un éditeur d'avoir une norme; mais laisse le processus ouvert pour (2)
(2) va produire (j'espére) un format qui n'est pas directement ni OOXML ni ODF, avec un effort nécessaire pour les éditeurs de logiciel d'avoir autre chose que son architecture interne dans un format XML (je pense que c'est valable pour OO et Microsoft Office (c) (r) (patent et co)).