xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: INFO : La guerre des clients SVG a-t-elle commencé ?
From: Robin Berjon (robin.berjon@expway.fr)
Date: 18/09/2003 - 15:58
Salut Eric,
Eric van der Vlist wrote:
> On Wed, 2003-09-17 at 15:08, Robin Berjon wrote:
>>j'ai décidé de m'inscrire ici pour répondre à cet article. Je dois dire que j'ai
>>été surpris, c'est là un des articles les moins informés que j'ai jamais eu
>>l'occasion de lire dans ces pages.
>
> Je suis désolé que tu le juges comme tel : nous avons pu passer à coté
> de certains points et ne sommes pas dans les secrets de Corel et Adobe
> mais cet article n'en a pas moins été écrit après avoir effectué des
> tests sur les produits qui y sont mentionnés.
Je ne suis pas non plus dans leurs secrets, même si j'ai l'occasion de converser
avec eux :) Ces deux sociétés étant à la fois concurrentes et coopérantes (au
sein du SVG WG), elles ne laissent naturellement filtrer que ce qui est nécessaire.
J'ai peut-être été quelque peu radical dans mon expression, mais connaissant les
efforts consentis par les deux pour produire une spécification qui convienne à
tous, et leurs engagements en faveur de l'interopérabilité n'ont pour l'instant
pas de raison d'être mis en doute, bien au contraire.
>>Il n'y a pas de guerre Adobe-Corel. C'est du pur sensationalisme. Les efforts
>>concertés déployés par ces deux sociétés pour produire des clients
>>interopérables sont réels et solides.
>
> L'expression "guerre des clients SVG" renvoie bien évidemment à
> l'expression "guerre des navigateurs" communément utilisée pour
> qualifier la rivalité qui a existé entre Microsoft et Netscape.
C'est bien là que l'assimilation des deux situations pose, pour moi, problème.
La guerre des navigateurs consistait principalement à rajouter toujours plus de
features non standard pour séduire les utilisateurs d'un coté ou de l'autre.
Elle ne concerne pas le moins du monde deux (ou plus) implémentations étant à ce
jour insuffisament conformes à une spécification.
La nuance est de taille car il y a d'une part de mauvaises intentions (faire du
propriétaire) et de l'autre un problème technique.
>>Il n'y a pas d'extensions propriétaires Corel.
>
> Tout depend de ce que l'on appelle extensions. Alexandre Arcouteil a
> constaté que les démonstrations de Corel faisaient appel à des
> extensions pour ce qui concerne les animations. C'est sans doute fait de
> manière tout à fait conforme aux spécifications SVG, en utilisant des
> espaces de noms pour bien identifier les extensions, mais c'est tout de
> même un problème pour l'interopérabilité des documents SVG utilisant ces
> extensions.
Les "extensions" de Corel sont présentes dans un namespace séparé et sont
implémentés coté client en EcmaScript. C'est non seulement conforme, mais c'est
aussi recommandé comme étant la bonne façon de produire des documents SVG d'une
certaine complexité (principalement pour les applications). Tout le monde le
pratique ainsi, moi-même j'utilisais déjà ce procédé avant que SVG 1.0 ne soit
une recommendation.
Une fois de plus, le DOM SVG et EcmaScript étant standard, les problèmes
rencontrés dans les browsers ne se posent pas. Hors bug (naturellement) les
extensions de Corel fonctionnent sous ASV3 (il y a des problèmes avec ASV6, mais
ce n'est même pas une alpha donc on n'en sera pas surpris).
L'interopérabilité est donc respectée, et de surcroît SVG 1.2 rajoute des façon
de déclarer et de gérer plus simplement des éléments dans d'autres namespaces
disposant de rendus SVG.
Aussi, Corel a soumis dSVG au SVG WG (comme on peut le voir dans le draft
actuel), bien que son sort n'a pas encore été décidé.
> A côté de cela, il a également constaté que le client Corel se
> comportait de manière assez moyenne sur les tests de la série "anim"
> publiés sur le site du W3C.
Le client Corel a été développé relativement récemment. Il n'est pas surprenant
qu'en peu de temps ils n'aient pas pu implémenter l'intégralité de la spécification.
Ceci touche à un autre problème, qui est celui des resources limitées amenées à
travailler sur une implémentation nécessairement complexe. Ceci dit les progrès
enregistrés entre chaque batteries de tests effectuées par le SVG WG sur un
ensemble assez large de viewers montre que tout converge vers de meilleures
implémentations (il y a de plus en plus de vert), et ce malgré le fait qu'il y a
de plus en plus d'implémentations et de plus en plus de tests :) De surcroît,
les zones mal gérées ont tendance à être aux mêmes endroits sur tous les clients
qui ne sont pas complets (ce qui aide l'utilisateur final).
Une guerre des clients représenterait une tendance, or la tendance est inverse.
> Bug ou pas, on peut penser que Corel à donné une certaine priorité à ses
> extensions par rapport au développement des fonctions standards...
Je doute que ce soient les mêmes équipes qui implémentent le moteur graphique de
relativement bas niveau d'un client SVG, et les widgets d'interface en EcmaScript :)
De plus, les extensions de Corel s'inscrivent dans le cadre du développement de
leur IDE, lequel génère du code dSVG dans du SVG -- de façon compatible. S'ils
avaient du attendre de finir le client pour travailler sur l'IDE, ils auraient
fait faillite avant...
Tout ce que pond l'IDE a été testé premièrement sur ASV3, ensuite sur CSV. Je
pense que Corel développe un client principalement pour ne pas avoir à dépendre
d'Adobe sur ce plan là.
>>Si le contenu de démo de Corel ne
>>marche pas ailleurs, ce sera le fait de bugs (comme ceux qui existent et sont
>>bien connus dans ASV 6 Tech Preview).
>
> Et des extensions implémentées au moyen d'espaces de noms propriétaires.
> On peu être inquiet quand on voit l'utilisation intensive qui est faite
> de l'espace de noms http://www.corel.com/schemas/2002/dSVG dans le
> document http://smartgraphics.corel.com/lightsdemo/lightsdemo.cxs (qui
> par ailleurs n'a pas une extension SVG).
Encore un fois, les espaces de noms propriétaires sont la façon *recommandée*
d'utiliser SVG, et elles sont *interopérables* quand elles sont faites
normalement (Il arrive qu'un client rajoute des extensions dans un namespace
donné pour pouvoir tester certaines choses ouvertement, mais elles sont
systématiquement marquées comme telles, et retirées des versions suivantes.
Comme c'est déjà arrivé, les développeurs y prêtent attention. Ceci n'est *pas*
le cas de dSVG).
>>Finalement il n'y a pas d'"arbitre" dans ce duel inexistant, et s'il y en avait
>>un ce ne serait pas nécessairement Batik. Il existe plusieurs dizaines de
>>clients SVG, rien de tout celà n'est guerrier.
>
> On ne peut pas nier que Corel et Adobe soient concurrents sur bien des
> points. L'image "duel" et/ou "guerre" est entrée dans le moeurs pour
> illustrer ce genre de rivalité et ne me semble pas choquante.
Je ne nie pas qu'il y a des rivalités entre Adobe et Corel, ou la qualité de
cette image, je nie qu'il y a un duel entre eux sur leurs clients SVG. Ce, tout
simplement parce qu'il n'existe pas.
> Je suis désolé que tu le penses et trouve au contraire qu'il n'est pas
> inutile de rappeler le danger que posent ce type d'extensions dans tout
> vocabulaire XML (SVG n'est hélas pas un cas isolé).
Certes, mais ça ne s'applique que quand extension il y a :)
--
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
--
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 30/09/2003 - 20:02 UTC
webmaster@xmlfr.org
| 
