L'architecture actuelle de SDX est fortement dépendante de l'architecture de Cocoon version 1. Cette architecture possède deux limites importantes :

1. Les informations échangées entre les différentes étapes d'un traitement sont en format XML et représentées par un arbre DOM (Document Object Model). Cela présente l'avantage d'être facile à manipuler, y compris de façon non séquentielle, mais présente aussi l'important inconvénient d'être gourmand en mémoire et lourd en traitement.

   La version 2 de Cocoon utilisera la spécification SAX (Simple API for XML) pour passer les informations d'une partie à l'autre, augmentant nettement les performances et diminuant les besoins en mémoire.

2. L'association entre les documents XML et leur feuille de style XSLT se fait à l'aide d'une instruction de traitement insérée dans le document. Pour de grandes collections de documents, cette pratique est totalement inédéquate. Dans la version 2 de Cocoon, un plan du site (sitemap) sera utilisé pour indiquer ces associations ainsi que d'autres informations.

La première limite implique plutôt les performances, mais il sera important de prévoir la migration de SDX vers ce modèle. Dans un premier temps, la feuille logique de SDX devra être modifiée pour tenir compte du changement d'architecture. Ensuite, les pages XSP des applications SDX devront être vérifiées afin d'identifier celles qui devront être modifiées.

La deuxième limite a des impacts moins évidents sur SDX, car a priori les applications SDX n'utilisent pas le mécanisme standard de Cocoon pour l'association des feuilles de styles XSLT. Toutefois, il sera intéressant de vérifier si l'utilisation du plan du site ne pourra pas améliorer la plate-forme.

La liste des fonctionnalités de la version 2 de SDX n'est pas encore arrêtée, et toute personne intéressée à suggérer des modifications est invité à le faire en écrivant à Martin Sévigny.

Pour l'instant, voici ce qui est déjà identifié :