xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: XML est les temps de traitements
From: abella free (fabella@free.fr)
Date: 26/09/2002 - 07:16
-----Message d'origine-----
De : Herve AGNOUX
>Oui, la technologie des compressions et des zip est connue depuis
longtemps,
>me semble-t-il... Et il n'est besoin d'aucun plug-in spécial pour
l'intégrer
>à IE : c'est déjà fait. (et dans Netscape aussi, d'ailleurs).
Votre réponse oriente le lecteur dans deux mauvaises directions : primo sur
notre méconnaissance d'algorithmes de compressions, deusio sur le fait que
ceux ci sont intégrés dans IE ou NETSCAPE.
Je laisse le premier point à votre seul jugement en ce qui concerne le
deuxième, j'avais lors de mon exposé précédent voulu ne pas trop
m'appesantir sur le sujet (d'ou la possibilité de me joindre directement)
mais je crois nécessaire de compléter mon explication. Dans des navigateurs
IE ou NETSCAPE et lors de l'utilisation de commandes UPLOAD, le logiciel
transmet directement le fichier sans effectuer d'opérations (pas de
compression). Notre plug permet de reconnaître des fichiers ayant des
entêtes du type que vous souhaiter (totalement paramétrable) et automatise
(avant envoi), la compression du fichier. J'ajouterai que l'intégration dans
les options des navigateurs d'outils tels que ZIP, permettent uniquement
d'automatiser la DECOMPRESSION à partir de la reconnaissance des
extensions....
>Le bon truc est de bien séparer ce qui relève du SAX de ce qui relève du
DOM.
>Et il n'est besoin d'aucune expérimentation pour être persuadé que ce truc
là
>fonctionne, et de toutes façons cela a déjà été expérimenté quantité et
>quantité de fois.
Encore une fois, je ne connais pas de processus informatique qui ne
nécessite pas d'être qualifier avant sa mise en production. Le fait que vous
soyez persuadé de son fonctionnement permet d'orienter une démarche dans une
direction donnée, mais n'est pas une condition suffisante pour qu'elle soit
viable. Dans mon discours précédent, je fais encore une fois part de mon
expérience sans pour cela dire que c'est cette solution qui est la meilleure
mais sous certaines conditions et avec certaines spécifications, elle a le
merite de bien fonctionner.
>Après, il existe encore d'autres pistes d'optimisation. Par exemple à
partir
>de l'analyse du schéma, vous pouvez savoir à l'avance quelle sera la (ou
les)
>prochaine(s) balise(s). Mais à ma connaissance il n'y a aucun produit de ce
>type, et aucun langage de schéma qui facilite vraiment cette approche.
>Néanmoins, dans un vocabulaire à "forte densité de variabilité", nul doute
>que cela pourrait être utile.
La démarche d'optimisation que vous préconisé ne peut fonctionner que dans
certain cas de figure. Elle implique que votre message soit bien formé dès
le départ et que les balises ne soient pas liées à des règles
fonctionnelles. Vous me permettrait d'ailleurs d'être à mon tour étonné par
cette "optimisation", sachant que la détermination de ou des balises
suivantes implique l'analyse de la grammaire du schéma. Chers programmeurs à
vos claviers !!!
>Sur ces langages de schémas je pense qu'il est possible de faire de gros
>progrès, dans le périmètre des échanges EDI. Par exemple, pour les
contrôles
>de validité, un "truc" connu est de disposer les informations de façon à
>n'avoir qu'une seule lecture à faire pour les analyser. Tous les langages
>informatiques (du moins... les plus utilisés...) sont construits de cette
>façon.
Je suppose que si je vous fais part du "truc", vous ferais peut être
référence de nouveau à un algorithme existant depuis des années. Donc cette
fois je m'en abstiendrais et j'attendrai avec impatience vos solutions
>Malheureusement cela n'a pas une grande importance pour le monde XML
puisque
>les documents sont en général assez petits, sauf dans le monde EDI, avec
ses
>messages à "forte volumétrie". Pour ce monde je pense qu'un langage de
schéma
>spécial serait utile, justement pour faciliter la mise en oeuvre de ces
>optimisations.
Il suffit de ce rendre compte de la très très faible volumétrie d'un
document WORD sauvegardé au format XML pour ce rendre compte
qu'effectivement, il n'y a que le monde EDI qui peut être concerné !!!
François Abella
Directeur Technique
www.qualicontrol.com
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 27/09/2002 - 09:22 UTC
webmaster@xmlfr.org
| 
