[This local archive copy mirrored from the canonical site: http://www.inria.fr/koala/colas/notes/xml-9803/xml-9803-notes.html; links may not have complete integrity, so use the canonical document at this URL if possible. See XML Developers' Day.]
ATTENTION : ce texte reflète mes (Colas Nahaboo) sur la XML Conference Seattle 23-27 mars 98 opinions PERSONNELLES, et n'engage en AUCUNE façon Dyade, Bull ou l'INRIA.
Ces Notes ont été prises durant la conférence sur mon fidèle PsionCeci sont mes notes prises durant la conf. Mes commentaires personnels seront sous ce format afin d'essayer de séparer une revue relativement objective de mes vues purement personnelles.
Les questions/réponses sont indiquées par des Q: et A:
Cette conférence est la 2eme sur XML, la première en 97 avait 1000 participants, cette année, près de 8000 personnes! Ce qui montre le succès que rencontre XML hors de sa niche SGML. Organisée par la GCA - Graphic Communication Association, sorte de club d'intérêt des industries de la publication écrite sur support papier, qui fut visiblement débordée dans son organisation par un tel succés. Ne connaissant que peu ce milieu (SGML), je peut avoir fait quelques erreurs ou omissions dans ce rapport. Je venais à cette conférence pour tenter de cerner les pourquoi du phénomène XML et rapporter un feeling sur l'adhésion à XML de l'industrie. Je dois dire que mes craintes ont été levées, et que il y a toute probabilité que XML se devienne le standard de stockage, d'interchange et de représentation de données dans un futur très proche. Quand a mes réticences techniques sur le format en lui-même, elles ont été balayées par la perspective des bénéfices qu'apporterait une telle standardisation !
Paul Grosso, Norman Walsh, ArborText
Ce tutorial est disponible online en: nwalsh.com/tutorials/xml98/xsl
Cette présentation est faite par les gens de ArborText, qui essayent de pousser ce standard, et distribuent gratuitement un éditeur de style sheets XSL, cf. www.arbortext.com (ou je suppose que l'on peut trouver plus d'infos sur XSL)
La première partie du talk aborde des considérations générales aux style sheets s'appliquant aussi bien a XSL que CSS (ou autres, DSSSL). L'idée est que les tags de markups insérés dans le texte ne soient la que pour décrire la structure, et comment rendre cette structure soit faite par une description a part, les style sheets. Mais la grosse différence est que XSL peut invoquer du code exécutable pour le rendu, en Javascript (ou ECMAScript plutôt, le Javascript normalise).
J'ai pose la question de savoir s'il n'avait pas peur d'avoir introduit le loup dans la bergerie de mettre du code dans un format, le rendant aussi inutilisable que latex ou postscript, mais bon il a éludé la question en disant que XSL avait une partie déclarative, qu'on pouvait ne pas utiliser de script, et qu'il s'attendait à ce que seuls les experts XSL scriptent.
XSL est pourtant un work-in-progress, poussé par plusieurs compagnies autour de ArborText. Le problème est qu'avec le temps, tous les produits majeurs du monde SGML ont fini par inventer chacun un langage de style sheets a eux. Il y a eu un effort commun, DSSSL, mais qui apparemment est un monstre de complexité (Le w3c a eu beaucoup de réticences face a XSL, ayant peur du monstre qu‘est DSSSL, et préférant une approche plus statique comme dans CSS). Grosso dit que sa crainte est que les vendeurs (de browsers, d'éditeurs...) ajoutent chacun leur features, que l'on aboutisse à un monstre non implémentable, qui soit brisé en plusieurs sous-systèmes, et que qu'on ait perdu l'interopérabilité. Il faisait partie du WG XML, et est fier d'avoir résisté à beaucoup de pressions du même genre.
Les choses s'articulent autour de 3 specs: XML, XLL (les liens), XSL.
XSL permet de formater suivant le contexte (type des ancêtres de l'élément), de réordonner les éléments, de générer du XML, et est indépendant de la direction d'écriture. XSL s'inspire très fortement de DSSSL (standard ISO en 92)(flow objects: Tables, paragraphes..., représentation de la structure, mais la syntaxe était scheme, XSL a remplacé la syntaxe lisp par XML), de sa version online: DSSSL-net, un peu de CSS (support de media non-papier: interaction, audio...). C'est si proche de DSSL qu'il existe un outil pour traduire du XSL en DSSSL. On peut penser que XSL se rapproche plus des systèmes de génération HTML que l'on trouve dans les bases de données que de CSS qui se veut plus dans la même niche écologique que HTML
Je suis un peu effraye par ce fait: En présence d'une bonne syntaxe (lisp) et d'un concept douteux (format procédural et non entièrement déclaratif comme CSS), ils jettent la syntaxe et gardent le scripting. Je suppose que c'est leur background de "print media" générant des documents inertes qui les aveugle. Mais bon, au cours de l'exposé je reviendrais sur mon opinion, c'est vrai que la partie déclarative de XSL est vraiment très puissante à elle seule. Mais le diable est dans les détails: pour récupérer la valeur d'un attribut, il faut scripter. Ils n'ont vraiment pas conscience des problèmes de l'interaction
XSL ne définit pas le formater, XSL n'est qu'un des inputs pour que le formateur fasse son boulot: on n'est pas en PDF ou postscript. Par exemple, on ne peut pas dire en combien de ligne va tenir un paragraphe, ou es règles d'hyphenation. Le formateur peut décider d'ignorer les infos des SS. Comme en DSSSL, le système parse le document en "flow objects", les passe à DSSSL ou XSL, qui renvoient des objets a formater dans un autre formalisme. (process n'existant pas en CSS, CSS1 ne faisant ni multicolonne ni header et footer). En gros XSL peut être vu comme générant du XML a partir de XML, avec au besoin un escape en script. Ils donnent même un exemple réel où des données sont extraites d'une base de donnes, formatées en XML via du perl, processées via XSL, puis le XML résultant est envoyé à encore un autre filtre XML avant être affiche! XSL est à XML ce que AWK est au fichier texte traditionnel UNIX (lignes de mots)
Exemples de XSL: la majorité sont des règles: un set de patterns (lies par un AND logique, il n'y a pas moyen de faire un OR autrement que de faire d'autres rules) ,et un résultat. Pour les patterns, les wildcards sont<element> et <any> (équivalents a . et *), on peut sélectionner par contexte ou attribute values (mais pas de regexp ni de match sur les character datas). En gros, on peut voir XSL comme un lex structure. Il donne ensuite des exemples intéressants ou des règles peuvent spécifier des choses comme "le premier élément de ce type déjà rencontre".
Lors du break, il y eut pas mal de questions intéressantes qui ont montré le danger qu'affronte XSL: le nombre de choses que veulent faire les usagers avec XSL est effarant (trier des donnes), combinées avec les implications que cela a sur les éditeurs (et non plus les simples browsers)
Pour les règles de génération. Il y a des meta-elements faisant référence à ce qui se trouve en input et matché par la partie gauche: <children/> (récurse sur les fils), <select-elements> (les éléments ayant matché), <eval> (insère le résultat d'un appel a Javascript), etc... par défaut., le contenu est outputté, si on veut le détruire il faut explicitement dire que ca produit un élément <empty/>. Il ressort des questions que le but est d'éviter le recours au scripting (dont l'interface avec les flow objets pour les récupérer est apparemment mal définie), et de rajouter au besoin tout ce qu'il faut comme actions de base pour ca.
On peut raffiner par des modes: en partie droite on peut setter un node dans lequel seront traite les fils, en partie gauche, si une règle appartient à un mode, elle ne s'appliquera que dans ce mode. Les règles par défaut s'appliquent quand même dans un mode si elles ne sont pas overidées par des règles spécifiques au mode, mais il y a un seul mode actif a la fois, ils ne "nestent" pas. Il y aussi des règles plus meta, les styles rules qui n'outputtent pas directement du XML mais modifient des attributs du XML qui matche *changer le texte en rouge...). On peut prédéfinir des styles complets (ensemble de valeurs d'attributs) pour les appliquer d'un coup. On peut aussi définir de macros en XSL qui seront expansées dans le corps par des appels au <invoke-macro>
Les scripts sont définis comme des données incluses (CDATA) dans des tags <define-script>, avec la contrainte de ne pas avoir d'effets de bord, sinon le rendu serait trop complexe, mais pour permettre aux browsers de l'implémenter facilement a l'aide de leur moteur Javascript déjà existant, les effets de bords éventuels peuvent ne pas être détectés (et une erreur) levée dans les applications. Les scripts sont appelles dans les valeurs d'attributs commençant par =, et via directement le tag <eval>
Effort en cours: working group crée depuis janvier 98. Il y a un outil XSL en Javascript
Une question intéressante: tout ca représente trop de donnes, ca va faire déborder mes documents du CD-ROM, est il question de compression?
J'étais à table à coté de vieux routards SGML, complètement surpris pas la visibilité que leur avait apporté XML. Il y avait le gars faisant le tutorial sur les liens (XLL, qui est en fait le système HyTime de SGML) qui disait qu'il proposait ce tutorial un peu partout mais le plus souvent ca n'était pas organisé faute de participants! (Cette conférence a été complète dès début mars!) Sinon, il y avait quand même quelqu'un d'une boite faisant du matériel médical venant voir s'il ne pouvait pas utiliser XML pour les protocoles inter-équipements, mais une dominante de cette conf etait que ces gens venaient la pour voir sans trop connaître le domaine et ne se manifestaient pas.
Une info assez représentative est qu'a Boeing et d'autres grosses boîtes, il commence à y avoir conflit entre les ingénieurs classant des données dans des bases de données (normalises par STEP), qui se mettent de plus en plus soit à archiver des docs, ou à pointer dessus, et les documentalistes qui utilisent des outils de plus en plus structurés, et il commence à y avoir des bagarres sur quel format de structuration doit s'imposer. La communauté SGML semble bien avoir pris conscience de l'enjeu, et se place "sur le tapis vert" pour occuper le terrain du cote des comités de normalisation.
Dianne Kennedy, Graphic Communications Association, Charles Frankston, Microsoft
infos en www.microsoft.com/xml
DK est consultant a GCA. Pour elle aussi cette conférence est une première, parce qu'elle touche un public très divers en dehors du publishing. L'exposé sera très pro, on voit que la communication graphique est son métier! CF, le cerveau derrière XDS restait en retrait derrière pour répondre aux questions.
J'abréverais XML-Data Schemas en XDS dans la suite, bien que cette abréviation ne soit pas mentionne par les auteurs de XDS
Présentation du modèle HARP pour publier ses idées :
Pour l'instant, l'industrie utilise en général un modèle HRP. L'intérêt de XML est de promouvoir le A dans HARP. Le problème de HTML est qu'il mélange A et R. Pour DK, il faut pousser HTML complètement dans R, et laisser XML faire le A.
Les bénéfices de XML: recherche plus précise, info conservée dans le client (on peut faire des manips offline).
Mais XML ne fait que la syntaxe, il faut de l'info sur ce que sont ces classes d'objets, c'est la qu'intervient la proposition XML-Data Schemas, de la sorte qui est déjà utilisée dans les bases de données relationnelles, car DK pense que dans beaucoup de cas les données que l'on veut encoder en XML proviennent de telles bases. Le but ultime est de merger les outils textuels et les bases de données relationnelles. (Elle consulte beaucoup dans l'industrie "lourde": Boeing, automobile), monde aux très grandes bases de données.
Q: RDF? (Ressource Description Format, effort de standardisation de " meta-URL " semblant s'enliser depuis un moment au W3C en guerres de chapelles de documentalistes)
A: XDS is hierarchical, RDF is plus une "moving target" décrivant des nœuds et des arcs, plus vague et moins utile.
La différence de XDS par rapport à une DTD c'est qu'elle offre plus de contrôle global: par exemple le fait que dans tout le document, on doive trouver une fois et une seule tel élément (From pour un email par exemple). Tous les éléments doivent être déclarés, avec une description optionnelle pour qu'un être humain s'y retrouve. L'orientation base de données se sent dans la définition d'élément <Any> qui remplace n'importe quel élément... sauf du texte brut!
# est un opérateur d'indirection: on peut exiger que un élément soit du type "lastname" par <élément type="#lastname">, et une notion de groupe intermédiaire pour spécifier l'ordre
Les Entités ( &xxxx; ) peuvent être internes (expansions de macros), ou a charger depuis l'extérieur, via un processeur pour inclure l'entité par la notion de "notation". (image gif...)
XDS permet la notion de Open Content Model, ou on tolère des tags non définis, ce qui est la réalité du web, wrt le monde rigide de SGML. Cela semble la très grosse addition de XDS par rapport aux DTD de SGML au point de vue de la communauté SGML. Open est le mode par défaut pour XDS.
Il y a aussi la notion de défaut de valeurs d'attributs, qui peut être dynamiquement changeable, et on peut avoir des aliases pour que le noms de tags (auteur pour author, etc...)
L'héritage est aussi diffèrent de XML: au lieu d'un simple héritage hiérarchique, on peut hériter de plusieurs objets, et on peut faire des groupes en dehors de toute hiérarchie. Un peu comme Java, il y a bien un héritage simple de l'implémentation, mais des interfaces permettant un héritage multiple fonctionnel déconnecté de la hiérarchie. D'ailleurs le modèle d'héritage est base sur java. <genus> est l'équivalent de "extends", Supertype est l'équivalent de "implements"
Mais, avec le modèle objet arrive le problème de name collision (si on combine des XML, les champs "title" vont entrer en conflit. La solution: les namespaces, introduits dans la spec depuis ce week-end :-), <?xml:namespace>, mais pas encore dans la spec w3c.
XDS m'a fait une excellente impression. Sous un déguisement SGML, il jette aux orties les vieilleries SGML, et remplace par des concepts plus propres... Il faudrait faire ca avec tout le standard SGML :-)
Bon, l'inconvénient est que ca vient de Microsoft, et je me demande si le fait de choisir une terminologie tordue (genus) ne vient pas de l'hostilité que MS pourrait avoir à utiliser des noms venant de Java. Et ca ressemble à du Evil Empire: prendre un standard ouvert (SGML), et y introduire des modifications a lui....
Je suis allé demander à la pause a Charles Frankston (le cerveau derrière la spec) s'il n'avait pas eu d'hostilité de la part de la communauté SGML (mais je verrai que cést un pieu mensonge, il a convaincu une partie de la communauté, il m'a dit que non, seulement) apparemment c'est très bien reçu. CF m'a fait d'ailleurs une forte impression de compétence et de clarté de vues.
DK (qui est une experte SGML, non-programmeuse) dit d'ailleurs que la dernière spec SGML fait 300 pages, que la dernière version a du être mise sur CD pour review tellement elle était grosse! Donc pour elle , le système de DTD était trop complexe. En plus ca évite de devoir apprendre ce qu'est une DTD pour les nouveaux arrivants venant de HTML.
Puis vient la description des relations dans XDS, basée sur les BD relationnelles (keys, foreign keys, join de databases...), et surtout le datatyping est indispensable: il faut par exemple impérativement savoir comment sont représentées les dates, par exemple pour le problème de l'an 2000
Un des usages de XDS est de servir de format d'interchange (ou de persistance) entre databases.
Leur vision c'est que de nouveaux outils grand public vont apparaître, et qu'ils implémenteront XDS, et non les DTD, donc DK plaide pour utiliser XDS pour le texte comme format commun et ne pas le cantonner aux bases de données.
Q: XDS permet de faire du XML non conforme (and group)
A: XDS est un superset de DTD. Or XML est défini par une DTD donc cette définition devra changer.
A mon avis ca va être à cette épreuve que l'on va pouvoir savoir si XML a une chance de réussir : Si les idées de XDS n'arrivent pas à percer pour cause de " bigoterie DTD ", l'avenir de XML risque d'en pâtir.
Q: XML a rencontre du succès car une contrainte était qu'un parseur XML devait être facile a implémenter (un week-end). Quid de xml-data ?
A: un validating parser XML ne se fait pas en un week-end! DOM est en train de bosser sur les object model, et CF espère que un validateur xml-data sera fait dans ce Working group. Il y a eu pas mal de questions de gens de SGML n'arrivant pas ont réaliser qu'on abandonnait le concept de DTD...
Q: Quid des autres compagnies? (des compétiteurs de MS)
A: il y a des représentants des databases vendeurs dans le comité, rien ne lie à dcom, com, java, beans...
Des stands surtout de 2 types: vendeurs de produits SGML classiques, et solutions "intranet d'entreprise" pour fournir des transferts de données via XML sur l'intranet d'entreprise. Rien d'enthousiasmant.
Adobe avait un stand frame 5.5, qui aura un module SGML et XML. Apparament Adobe essaie de rentrer en force sur le marché XML, et essaye de débaucher le plus de monde possible des boîtes traditionnelles SGML
intro par un des (le?) Directeurs de le GCA, présentant son association, qui va essayer de faire des offres aux droits d'entrée plus abordables vers le commerce électronique, et non plus "l'industrie lourde" de la publication. Il annonce d'ailleurs que la prochaine conf. XML cet été sur la cote est sera orientée business. Un groupe XML-EDI (Electronic Data Interchange, échange de données business) a déjà été formé, preuve de la percée de XML dans ce monde.
Jean Paoli, Microsoft
Chairman : Etait à Grif, puis est responsable de logiciels a Microsoft, dont IE. A dirige le support de XML dans MSIE 4.
Adam Bosworth, General Manager, Microsoft Corporation
AB invite softquad a démontrer ce qui se fait à présent avec XML: une architecture 3-tiered: les données en provenance d'une base de données sont mise en forme par un présentation manager avant d'être envoyées au client.
L'appli de softquad est intéressante, sur le site de softland, une compagnie aérienne, où suivant les vols choisis on voit les destinations gratuites (bonus miles) s'updater en direct. C'est une combinaison de DHTML et XML. Les donnes sont envoyées "brutes de database" en XML, et le DHTML les manipule et génère les tables, formats en direct dans le client.
2eme demo, visible sur le site ms: www.microsoft.com/xml "auction", vente de tableaux. Là encore, on downloade la database des objets sur le client, puis le client la parcourt sans accès au serveur. AB insiste sur le fait que cette demo pourrait être faite sans aucun produit MS, ou même en java, puisque la seule chose qui passe entre vendeur et client est du XML,"lingua franca".
Puis, sur les services rendus, il voit surtout immédiatement un meilleur search, actuellement on ne peut pas chercher un bouquin particulier "out of print", ou une baby sitter,... Et XML permet de le faire sans obliger le vendeur a changer son modèle de base de donnes puisqu'il y a conversion (et non pas accès direct comme via CORBA).
Lessons from the web: Simplicity wins (open, easy, flexible), efficiency loses (complex, fixed binary formats). C'est ce qui permet au plus grand nombre de participer qui gagne.
Par analogie a un supermarché il plaide pour avoir des web transaction à gros grains: acheter un produit a la fois engorgerait tout le système... comme il engorge les serveurs web en ce moment, de même il faut peu de multitask (si une caissière traite plusieurs clients en même temps, on ne s'en sort pas), des queues (sinon c'est le chaos), un modèle interruptible (si un chèque prend du temps a valider, il faut pouvoir traiter le consommateur suivant pendant ce temps), des standards (codes barres)
L'idée est donc de garder une archi 3-tiers mais intermédiaire : on formate tout en brut en XML et on laisse le soin au client de faire l'UI complète de tout ca. Pour lui le futur est XML inside DHTML: CSS + script, et XSL. Pour cela, ils ont sorti un free XML java parser sur leur site. Il encourage a apprendre et utiliser XML, puis de définir des grammaires spécifiques a des domaines, même si l'implémentation d'outils sur ces grammaires spécialisées ou le support dans les browsers n'arrivera pas de suite.
Là encore, MS fait preuve d'une vision très claire et saine du domaine, en utilisant XML vraiment comme un format de données ouvert et complètement déconnecté de ses racines SGML, le révélateur étant l'absence de texte en vrac (character data) dans ses exemples, qui signe une rupture avec le lignage " markup language " SGML. XML est vu comment un langage d'interchange de bases de données, et non plus du tout comme un langage de présentation. Nulle part en effet XML ne sert à formater du texte, ni même a en exprimer la structure! C'est la "media indépendance" très peu prisée dans le monde des browsers, y compris NS et MSIE, surtout après l'épisode lamentable des contrats d'exclusivité l'année dernière forçant des sites a n'être accessible que sous MSIE...
JB souligne l'énorme étendue du nombre d'industriels qui participent au WG XML, MS n'a ni démarré ( XML date de 18 mois) ni ne contrôle XML "XML is a conspiracy, but not by MS". Vu le momentum, il se sent désormais assez sur pour affirmer que XML va devenir le langage du web, et en plus que ca va devenir LE langage de représentation de données en général! XML is NOT a markup language! XML remplace SGML, HTML est généré par SGML, pas le même domaine. No semantics in XML!
Une autre vue est de dire que XML a été un " coup d état ". XML ayant été fait dans la clandestinité par des ayatollahs SGML self-appointed sans input du monde éxtérieur. Mais ce point de vue ne sést pas exprimé à voix haute durant cette conf.
XML namespaces sera releasé en avril, le travail se repartit en 4 groupes indépendants: XML,XLL, XSL, namespaces.
Les namespaces seront présentés au developers day. En gros on définit des préfixes simples aux attributs que l'on écrit namespace:name, et on donne une URL qui servira de définition de l'attribut. Sera utilise par RDF, PICS, MathML. Le système des namespace est minimal pour être sur qu'il marche
plan prévisionnel non approuve:
finish namespace, comment associer XML aux stylesheets, rajeunir les DTD (étendre, et les écrire en XML), educational material, standard XML user agent behavior, validation,
Q: how to embed binary formats with structure?
A: maybe last item in plan: packaging
Q: why not a common language
A: it would fail (too big) "too bad it doesnt work"
Elle fait une analogie avec le Word Processing: les premiers systèmes avaient de la structure, puis le WYSIWYG est arrive, mais progressivement in redécouvre la structure. En HTML le tag A a joué ce rôle du WYSIWYG alors que les systèmes hypertexte précédents étaient déjà assez sophistiques. Le groupe XLL n'est pas encore formel mais va se séparer bientôt du groupe XML ou les travaux sont faits en ce moment.
features:créer des liens depuis des pages non-writables (CDs, sites distants, updates....) Design goals: quick, formal, concise and pratical. Le principe est de passer par des link databases externes de lins, qui permet un update plus facile, un gestion coopérative...
XLL inclut XPointers permettant de représenter un chemin dans un arbre (un document XML), mais XLL et XPointers peuvent être utilises séparément. Basé sur l' "extended pointer specification" de Text Encoding Initiative (TEI). On peut spécifier par un mix de paths ou IDs embedded dans la destinations, va utiliser DOM.
Cf. Tutorial en début de rapport.
Q: que va-t-il falloir rajouter aux parsers pour traiter, XLL, XSL, namespaces... ?
A: we dont know exactly, but each effort tries to avoid implementation problems,
Q: what about print?
A: not yet really taken into acount, but will in the future. Soyez rassurés par la présence d'Adobe et autres compagnies de print.
Chis Lilley fait une demo d'un browser pour un XML pour les bioengineering (avec codes ADN)
J'avais organisé une table ronde sur le sujet "XML binary format", mais j'ai eu tort car l'intitule a apparemment fait peur a la communauté. J'ai quand même pu attirer 2 personnes motivées (dont Rohit Khare), pour l'échange de données, notamment des systèmes permettant de récupérer des données progressivement, dans un flux. Il faudra que j'essaie de monter un effort éducatif avec Bert pour faire passer l'idée en douceur. A cette table étaient présents Eve Maler (XLL) et Steve De Rose (metadata), et leur réaction a XML-Data fut édifiante (Eve: "Dont start me on that!"). Ils lui sont tout à fait oppose, car XDS ne passe pas dans le moule du comité XML (abandon du formalisme DTD), le principal reproche étant d'incorporer dans XDS 3 ou 4 concepts (datatyping, keys...)qui auraient pu se développer indépendamment au sein du comité XML (comme XLL, namespaces....)
Adam Denning, Microsoft Corporation
message: XML for data, HTML for display.
en IE4 il y a un parseur XML, un XML Object model
MS Donne des parseurs free C++ et java, qui permettent la manipulation de l'arbre après coup. Les parseurs fournissent un arbres d'éléments qui ont comme champs tag, type, text, parent, children,
XML DSO: moyen de dire que le XML qui suit vient d'une source externe (database)
Mais le gros de l'expose se contente de reprendre ce qui a déjà été dit dans les autres exposes (XSL, XDS)
Des questions il ressort que DOM n'étant pas encore finalise, on attend encore des décisions (est ce que le texte embeddé dans XML sera représenté sous forme de pseudo noeuds ou pas ?)
Dr. Charles F. Goldfarb, Information Management
re-expose le modèle HARP (cf plus haut), et plaide pour séparation du style des données, car le style est très important pour la communication humaine, mais change avec les époques. Style is too important to get mixed with data!
Cette vue, a l'opposé des vues techniques (les data sont importants) est intéressantes, car elle retourne le problème mais avec la même conclusion: séparer data et style!
Il est intéressant de noter que c'est le même argument avancé par les critiques de l'approche " markup language " SGML et XML, et qui prônent une séparation du texte brut et des infos de markup dans un deuxième fichier décrivant les styles à appliquer au texte, via des pointeurs dans celui-ci. Mais vu le momentum de HTML et XML, ces considérations n'ont plus qu'une importance historique.
Doug Tidwell, IBM Corporation
Même topo que les autres: 3-tiers application: XML + XSL... Sa stratégie est de fournir aussi des java servlets pour générer de l'HTML depuis XML sur le serveur au lieu du client pour les browsers simples.
il dit que XML + DHTML risque de remplacer java sur les web pages, java étant très sous utilisé (sert la plupart du temps du bête data entry)
Prêche pour supporter tous les browsers, et ne pas imposer XML ou DHTML dans les browsers.
Steve DeRose, Inso Corporation
Un exposé au nom trompeur, puisqu'il s'agit là en fait des metadatas et non pas exactement de la proposition de XDS, ou alors de la même mais interprétée différemment d'une façon bien plus meta et moins opérationnelle, plus comme description flexible de formats d'échange que comme format pivot.
L'exposé sera malheureusement confus et vague, on a du mal a savoir qu'est ce qu'il veut faire et comment
il y a 3 sortes de meta data:
data arrangement: comment sont organisées les données, depuis l'encodage au niveau des bits (ascii, hex, BDC), des datums (formats des dates, des réels..) a l'organisation générale (chapitre, abstract...)
Dr.Lauren Wood, SoftQuad, Inc.
comme le Dr. l'indique elle est allemande :-)
DOM est la colle entre les langages de programmation et XML/HTML. Ce n'est pas juste le parse tree, mais une API. Le but est de généraliser DHTML, a des langages autres que Javascript, et pour des applications non graphiques.
DOM est un trade-off entre une spécification complète mais lourde (qui donnerait près de 3000 fonctions dans l'API) a spécifier et implémenter, et une spécification légère mais moins utile pour les applications.
Son usage serait de pouvoir prendre un document, de l'analyser et pour le re-rendre différemment (synthèse vocale... etc...)
L'expose était là encore peu clair. Elle n'a pas parle de fonctions de modification, et a insiste sur des fonctions qui sont plus du domaine de XML+un langage. DOM pourrait aussi être utile en dehors du cadre des browsers web, pour servir de standard d'API aux parseurs XML " tree ", comme SAX l'est pour les parseurs XML " stream ". A voir...
Dick Bartels, Poet Software dirk@poet.com
XML va être utilisé pour traiter des données qui vont devenir énormes. Il plaide donc pour le besoin d'un XML repository. En fait, il veut entre autre un moyen de stoker l'arbre de données XML en format rapidement parsable, via un persistence service, comme un "cache XML" au niveau client. Mais il le faudrait aussi flexible pour s'adapter au format des bases de données legacy. Il l'appelle "native XML format", mais ce format serait propre à chaque appli, il ne voit pas le besoin de le standardiser.
Le repository serait une "base de données XML" avec un accès via une API., Qui passerait aussi a l'échelle en nombre d'accès concurrents.
choix d'implémentation:
Expose long, verbeux et terne. Dommage, le sujet aurait mérité bien plus, avec qqun ayant plus de recul et de vision
J'ai pose la question sur l'usage de son native format comme format binaire, mais il ne semble pas avoir compris l'intérêt, et voit ce format binaire différer selon les implémentations.
Dan Connolly, Architecture Domain Leader and XML Activity Lead, W3C
Présentation du w3c. Plus de 250 membres actuellement. Plus de 50 dans le staff.
XML arrive à point nommé pour les boites qui ont des besoin d'organiser des données de tailles de plus en plus grosses et que SGML ne savait pas résoudre. Pour lui, l'inconvénient des binary format est le problème du debug, qui est un petit frein en théorie mais très pénible en pratique. Quels que soient les pb d'efficacité, le format ascii est extrêmement parlant. Il cite le cas de gens capable de seduire des venture capitalists en leur montrant du XML: "yes, this I understand"
Il est surpris du succès "people seem to prefer pointy brackets to round brackets". Pour lui HTML ne disparaîtra pas, sa simplicité et son universalité lui permettre de répondre à la majorité des problèmes.
A priori, out doit être fait en WG sauf dans les cas délicats qui impactent beaucoup (privacy, metadata, qui interagissent avec le caching)
Slides en www.w3.org/Talks/9803xml-seattle/ Evolution of Web Data Formats
DC semble avoir été la " taupe SGML " au sein du W3C ayant permis le " coup d'état " XML dans sans coin sans en informer le reste de la communauté WWW.
Q: XML ISO standard?
A: ne pense pas.il y a du feedback dans les 2 sens mais, a son avis, ca ira pas plus loin.
Q: pb del'industrie auto, les données deviennent énormes
A:pense qu'il peut y avoir des binary formats non généraux domaine spécifique mais ne pense pas qu'un format binaire s'imposera
Q différences avec ISO
A: iso = un vote par pays, et les documents fixant les standards sont payants (IETF et ecma gratuits)
En passant dans les différentes tracks, il a été surpris de voir beaucoup de discussions techniques dans les groupes business, et réciproquement il s'attend à ce que dans la track technique on parle pas mal de business.
fait une analogie entre ces premières confs et les premiers InternetWorld. Il y avait un fort pourcentage de techniciens, puis le domaine a explosé après. Il pense aussi que l'explosion va être inouïe car pour la première fois on pourra ne pas re-inventer la couche de base comme a chaque génération de techno: les stacks IP,les ISP, les browsers sont déjà la!
Il présente un système qui permet de sauver un document pour le publier, pour faire le pendant du read ou on peut charger un fichier de la même façon dans un browser que dans un desktop
Selon lui l'avenir est
Encore un expose fumeux et bateau qui suppose que tout va devenir possible car on pourra échanger de l'information structurée comme si on ne le pouvait pas avant. C'est un peu comme s'il disait: maintenant qu'il existe RTF, tous les traitements de texte seront compatibles...
Une des questions fut notamment de savoir comment remplacer les protocoles actuels d'échange de données (CORBA COM..) La réponse fut: non, pas la peine, XML coexistera (sous-entendu : pas la peine de lutter de front, XML s'imposera ;-)
Christophe Lecluse, AIS Software
En un fort accent français :-), il présente une application déjà déployée (pas encore en XML) en France et en Europe par un constructeur automobile français permettant d'accéder à un catalogue de pièces automobile (sur le web dans le futur, en fait sur 5 CDs en ce moment, pour éviter de se connecter). (Un IPC = Illustrated Parts Catalog) pour que les garagistes puissent commander des pièces détachées. La problématique est ici plus l'efficacité et la précision que l'aide online (les usagers sont des experts du domaine)
La problématique est différente de l'aviation ou il y a assez peu de modèles, et donc ou il y a un catalogue par modèle d'avion. Pour les voitures, la combinatoire serait trop fortes (trop d'options: diesel, direction assistée... etc). Donc les données dans la base sont "étiquetées" par du XML donnant l'"applicability" (la liste des cas dans laquelle cette pièce existe), et l'appli web doit matcher ces applicability tags.
L'intérêt de XML par rapport à HTML, c'est un pb d'engorgement du serveur: avec des milliers de clients en même temps, la " méthode CGI " va effondrer le serveur: XML permet de faire des transactions plus grosses mais moins nombreuses. Cette plus grande granularité fait aussi que le serveur n'a pas a connaître les détails de ce qui est dans les grains.
La question que je me pose (et le public aussi), c'est que la taille des données XML a transmettre peut être énorme si le serveur ne filtre plus!
Ils ont un prototype: base de données SQL -> XML -> (client) ActiveX générant le HTML via XSL et bricolage
Castedo Ellerman, Microsoft Corporation
CDF est le format décrivant au browser comment actualiser automatiquement les données depuis un serveur, le fameux "push"tant hypé l année dernière. Il assure 3 fonctions principales :
J'ai eu l'impression que CDF n'était du mauvais microsoft: un truc quick n dirty, sans énormément réflexion (le système définit des tas de façons de respecter le temps, mais ne prend pas en compte le problème des timezones!!!). Mais bon, c'était la première appli de XML...
John Tigue, Datachannel
(slides dispo sur le site de datachannel)
XML for Distributed Computing: WebBroker by John Tigue (March 26, 1998)
WebBroker est un proxy CORBA, COM, ou COM+ (COM orienté-objet) via des messages codes en XML. Le proto utilise les standards web, pour client ->serveur il utilise la méthode POST (CGI), et des java servlets sur le serveur, et cote client du java + une applet serveur web pour les invocations serveur->client. A propos des servlets, il dit que seul JRun marche correctement (by far the best)
Plusieurs DTD ont été écrites: (seules les 2 premières passent sur le wire)
Il emploie un gros hack pour accélérer le tout: des DTDs réduites avec des tags a une seule lettre! Va essayer de proposer ces DTDs comme standard, et est en train de code les outils pour générer les proxies et les stubs automatiquement.
Q: par rapporta COM ou CORBA?
A: venant du monde WindowsNT, il connaît bien COM qui a des nasty détails, COM+ va vers CORBA, et pour lui au final COM+ et CORBA vont finir par être équivalents à sa solution, finalement tout va se ressembler...
Je suis allé le voir pour demander s'il ne serait pas intéressé par un format binaire. Apres une première réaction de recul "jamais vous ne ferez standardiser un format binaire par le w3c", il a eu l'air intéressé par discuter après d'améliorations au protocole pour les gens faisant du transfert de données. Mais selon lui, le tout est de s'unir pour assurer le succès de XML dans l'industrie. Pour les détails techniques, il sera bien temps de voir après.
Je me suis mis à une table sur l'interopérabilité des applications, mais finalement la discussion n'a pas eu lieu. J'ai discute avec un américain qui avait passe 3 ans... a Bull Gambetta (a l'époque de la préparation du DPS7). C'est un consultant indépendant qui forme les programmeurs de boites en Visual Basic. Il est venu à cette conférence pour s'informer sur XML, sentant que ca avait un rôle a jouer, mais en ne pressentant pas encore lequel, comme la plupart de l'assistance de cette conf il me semble.
B. Tommie Usdin, Mulberry Technologies
Elle a une grosse expérience en design de DTD pour des industries de composants électroniques. Trouver des infos dans des donnes, c'est à la fois dur de trouver ce qu'on veut et surtout de mesurer la relevance de ce qu'on a trouve. Avoir de la structure (grammaire) via XML permet de chercher lus efficacement, et surtout d'éliminer plus facilement ce que l'on ne veut pas.
Pour maximiser la recherche, en plus de la grammaire, il faut du vocabulaire (ensemble de mots clefs). Le problème des textes humains c'est qu'ils sont chaotiques: souvent ils ne disent pas de quoi ils parlent, et un bon écrivain va essayer de varier ses termes. Il est très important de donner à l'avance les mots clefs et surtout ne pas les laisser choisir au hasard.
Le problème de l'indexage c'est que les designer des indexes ne sont pas ceux qui l'utilisent, donc l'adéquation est longue et difficile. "users are perpetually surprising", il faut sans arrêt vérifier quel mots clés parlent aux users.
prédictions: Il y aura des grammaires XML, mais par contre les vocabulaires communs vont être long est venir, car contrairement aux grammaires, les techniciens sont familiers avec les grammaires mais pas avec les vocabulaires. On va assister à une industrie de la vente de vocabulaires commerciaux.
Mais ce système ne s'adresse qu'a des utilisateurs sachant ce qu'ils veulent... "there is no hope for the clueless"
David Singer, IBM San jose (a la place de Eric Miller). DS est chef du groupe de travail RDF au w3c.
slides en W3C Resource Description Framework . Il y aura des discussions plus en détail a la conf. XML/SGML de paris.
2 groupes Model & syntaxe (chair EM, public draft oct 97), et le schema working group (chair DS, public draft fev 98). Cet effort est dérivé de PICS, créé en vitesse pour contrer une censure politique, qui a été fait de façon la plus ouverte possible, avec 2 erreurs: types de données seulement numériques, et syntaxe lisp. Puis, cette direction a intéressé les gens voulant faire des site maps, et les bibliothécaires.
RDF est un modèle, organisé en graphe avec des cycles potentiels, serialisé en XML. RDF consiste en ressources ayant des properties pointant (graphe) vers des valeurs qui sont d'autres ressources ou des donnes primitives (strings, ints)
RDF peut être embeddé dans le document, ou dans le header HTTP comme PICS, ou un 3rd party.
Paul Grosso, ArborText
Cf. le tutorial.
Q: XSL semble très peu interactif
Q: support dans les browsers
A: NS pas au début du WG mais s'est joint récemment. pas de commitement.
Q: qui va définir les flow objects? Et si on veut des flow objects VRML ?
A: il faudra redemander un standard au W3C
Q: pb des fontes
A: CSS est plus avance que DSSSL, donc a court terme le mieux est de générer du HTML+CSS
Q: d'un mec inquiet de plus pouvoir touiller son html au pixel près avec XSL
A: utiliser postscript! le but du système est justement de pouvoir avoir des style sheets radicalement différentes selon les usages
Michael Vizard, Executive Editor/VP, News, Infoworld
Il voit l'explosion de XML: technique en 98 (standards), outils en 99 (éditeurs), industrie en l'an 2000. XML n'a pas d'avantage technique pas rapport à tout ce qui a été fait auparavant, il arrive juste au bon moment
SUN a présenté un framework pour faire du XML via les javabeans
Pour lui, les techniciens dans les boites poussent pour XML, mais les marketeurs ne voient pas de quoi il s'agit.
XML va être un moyen de sortir des guerres IE/NS, java/ActiveX...
XML redonne la priorité aux données l'OS a moins d'importance. SUN pousse beans + XML, et MS semble pousser XML car "tout sauf java" :-)
pitfalls: fragmentation a la "embrace and extend", pas de coopération entre boites, déception par rapport au hype, résistance des leaders actuels (search engines), qui va manager les tags?, HTML bigotry (des tas de gens font de l'info en ne connaissant que HTML sans background en info)
Un ensemble de représentants de boites conseillant les entreprises sur les technos émergentes, boites de veille technologiques.
Jerry Michalski, Managing Editor, Release 1.0
Mary LaPlante, CAPV firme de consulting a boston spécialisée dans les documents
Jeffrey.P. Morgenthal, NC Focus. Firmes de conseil de technos émergentes.
Michael Goulde, Patricia Seybold Group
Heather Knox gartner group.
Ce panel d'experts avait pour but de faire passer auprès d'une audience de developpeurs leur connaissance du monde du business et des managers en dehors du monde de l'info, qui constituent leurs clients, pour donner à leur avis les recettes pouvant aider à répandre XML hors de son cercle d'initiés,
de ce panel, HK et JM sortaient visiblement du lot, JPM avait l'air bien pipeau et les autres dans la bonne moyens
Ca a commence par un sondage en direct dans la salle: la plupart des gens venaient de l'application développement, peu de SGML ou du web, ce qui a eu l'air de surprendre fortement le panel, qui semblait s'attendre à une forte communauté SGML et web.
HK: de plus en plus je me retrouve a suggérer aux clients de regarder XML comme solution a leur pb, les businessmen sont plus facilement convaincus que les techniques qui s'accrochent plus a leurs technos familières.
MLP; moyen de vendre la techno aux businessmen: dire que XML est le moyen de construire une relation de long terme de confiance avec le client.
MG: "nothing suceeds like sucess": je vous encourage à choisir des applis simple et bien cernées pour démontrer la faisabilité de XML dans l'entreprise
HK: le plus dur est de savoir la structure sous-jacentes du problème
JM: c'est bien beau mais rien que pour les traitements de texte, soit on prend un TDT SGML, hyper dur a utiliser, soit ce sont des traitement de texte bordéliques.
HK: il va falloir en profiter pour passer à une génération suivante d'outils d'authoring, écrire un document fait appel en fait à plein d'activités humaines (recherche, coopération) non encore présentes dans les outils actuels.
ML: c'est de votre responsabilité (clients) de ne pas accepter de solutions non-standards (w3c).
MG: j'ai été dans beaucoup de consortiums (OSF.) Et ca n'avançait pas vite et pas grand chose en sortait. La différence ici c'est le cote parallélisme et distribué du process.
prochain developers day 29 aout a Montréal
David Megginson, Microstar
SAX vient du fait que l'auteur de jumbo a pété les plombs en voyant arriver le parseur de microstar qui etait le 4eme, avec chacun une API différente.
SAX est une API commune atout ces parseurs, basée sur une architecture de stream a base d'événements, car c'est la plus simple a implémenter pour les parseurs, et ca demande moins de mémoire intermédiaire: par exemple, il peut parser un document de 4M en moins de 2M de RAM, car sinon en mettant tout le tree en mémoire, ca prendrait plus de 49M ! C'est important pour les gros documents (SGML, databases), pour faire de la tree transformation. Mais évidemment, on perd énormément d'infos et de confort pour l'usager.
Il a semble impliquer que les parseurs "tree" devraient se baser sur le modèle de DOM, qui va setter le standard pour les représentation des parse tree XML.
SAX ne vise pas a être un standard. Il a été développé coopérativement, et du coup est bien meilleur que s'il l'avait fait tout seul dans son coin comme produit propriétaire de microstar. "The leader of a free efoort, should not be smart, just smart enough to recognize who is smarter than him"
SAX est extrêmement utile combine a java, qui permet de changer de parseur au vol en changeant le CLASSPATH. On peut utilise de gros parseurs de debug, ou de très simples assez petits pour être downloade dans le client. Par contre, on ne peut pas (encore?) Faire d'éditeurs de XML en sax, car on perd de l'info (commentaires, source des entités) au parsing.
Dans les ajouts, il prévoit de passer plus d'infos, notamment les Nos de lignes pour pouvoir reporter les erreurs de façon plus utile.
Naohiko Uramoto, Hiroshi Maruyama, and Kento Tamura, IBM Tokyo.
www.alphaworks.ibm.com/formula/xml xml4j.jar, ~240k
XML for java (trlxml) a commence à être développé en août 97
buts: robuste (ne pas aborter a la première erreur), support de 18 différents encoding, standards compliance (XML, partie de DOM, SAX...), validating (et permet à l'appli de savoir ce qui est permis dans par la DTD dans les éléments).
Crée un tree en mémoire, on peut overrider le comportement par défaut de la création des nœuds en définissant des ElementFactory qui vont créer leur propre elements
futur plans: suivre évolution DOM, SAX, namespaces. Version light pour embarquer, support de digital signature for XML, intégration dans d'autres outils, RDF, XSL..., support de XPointers?
demos dispo: site outliner, CDF editor
Steph Tryphonas, Microstar
Un outil pour convertir des (énormes) DTD SGML en DTD XML.(Et éventuellement générer directement des pages web de données SGML). Il l'a développé en regardant les grosses DTDs existantes (une trentaine pour l'instant). Il e fait automatiquement, ou guidé (donne des choix, construit des règles a partir de briques prédéfinies: Types existants, and, or, SDATA...) ou en manuel suivant les cas.
Il a recommandé la lecture de www.w3.org/TR/NOTE-sgml-xml, et est prêt a aider quiconque a des pb de conversion de DTD.
Larry Wall, O'Reilly, and Dick Hardt, ActiveState
ActiveState est une boite faisant un perl debugger, un postscript debugger, et des kits d'install perl.
LW ne savait pas ce qu'etait une DTD il y a un an.Perl est un des outils majeur de manipulation de texte depuis maintenant 10 ans, et LW sent que le texte du futur sera XML Pour ce il faut supporter unicode,LW a choisi de supporter unicode 8bits (UTF-8 au lieu de 16)
Design goals: ne pas casser de programmes existants, convertir de prog a UTF en une decl, garder la même langage (pas de variantes).
Implication: les parties unicode doivent être scopees statiquement, les commandes de positionnement dans les chaînes doivent être en caractères et plus en bytes, support dans les regular expressions, traduction des caractères et classes de caractères doivent être fait de façons sioux, faire des tables indexées par character code peut exploser, pack&unpack, IO filters, et ds le futur pouvoir écrire le programme perl lui-même en unicode.
Perl et XML se marient bien car complémentaires: perl est élégant, flexible, chaotique et permissif, XML est normalise, rigide, prédictible et légaliste.
XML peut être vu comme l'ADN de perl
XML est représenté en perl comme un arbre d'objets perl. (Elément a 2 listes : d'attributes et de children)
XML a donc un module parser XML, basé sur expat de James Clark, efficace, robuste, qui convertit en UTF-8, pas encore compatible sax mais pas loin. Les constructeurs du tag foo sont les fonctions foo (début) et foo_ (fin). Il permet de demander le texte raw, sans l'expansion des entités
futur: SAX, autodetection, regexp sur XML, puis les fonctions tordues de perl marchant directement pour XML.
LW n'a pas protégé sa work partition, donc pour voir le snapshot courant, il suffit de faire mount.
"XML is not that all readable".
Q: pourquoi pas UTF16 (va être le plus populaire au japon)
A: bof. c'est un pb de transition. A long terme tout sera 16bits. Perl a déjà été japonisé plusieurs fois, mais de façon inconsistante
Ses slides étaient écrites en XML! (avec un moteur de conversion en perl)
Scott Parnell, Xerox Scott_Parnell@wb.xerox.com
Le besoin était de gérer tous les documents xerox de façon unifiée, pas chère et distribuée. Ont donc choisi java + le parser XML Microsoft (qui utilisait des factory), java Beans, JFC.
Sa tendance est de mettre le plus possible d'info dans le XML du document et de moins en moins dans la programmation java qui interprète ce XML pour le rendre. Les qualités de designer de format de document deviennent donc de plus en plus importantes, par rapport au qualités de designer/programmeur qui importaient avant. 99% du java est plug n play de classes existantes. (il a eu la critiques que si son système était en XML+XSL il n'y aurait pas eu besoin de programmeur du tout)
Henry Thompson, U. of Edinburgh
www.ltg.ed.ac.uk/~ht/xed.html
slides en XML créés sur XED, puis génération de HTML avec un XSL crée par XED via XSLJ et JADE.
XED est un free smart text editor, qui ne peut construire que des documents well-formed. Pas fait pour les gros (> 1M) docs, comme expérimentation des user interfaces adéquate pour l'édition de texte structures. Construit en Python, avec un parseur XML Python. A choisi python car bien OO et sa bonne interface a TK, qui a un très bon text widget pour tagger les attributs des objets. Pb: Tk ni python ne sont encore unicode. Versions unix, windows, et bientôt Macintosh, avec keybindings naturels par plate-forme (emacs, windows....). Text editor (on voit les tags), et non un document editor
Il se sert tout le temps de XED, pour être aussi rapide que le psgml mode de emacs. Le but était de "practice what you preach" et d'utiliser ses outils.
Se présente comme notepad, et sur la frappe de < il poppe un menu des tags possibles ((base sur l'historique de ceux déjà vus ailleurs dans ce contexte, ne parse pas la DTD. Ne laisse taper que ce qui est possible, et a l'undo illimité.
De la même façon il refuse la frappe des caractères illégaux (}}> ds cdata, que des nombres ds &# ...)
Demo très intéressante: il essaye de faire un produit utilisable pour le power user, de l'ergonomie non flashy efficace, vraiment classe. Des methodes telles qu'on aimerait en voir plus souvent !
Problèmes: les entités.
C'est plus dur pour lui de faire un text editor pour XML que un document editor structuré classique. Mais targette pour des utilisateur naïfs en XML/SGML. Elle permet de réunir les utilisateurs de emacs/latex/unix et de windows/Word. Il ne peut pour l'instant pas le faire sur DOM qui abstrait trop de choses.
Un exemple de bug: taper ]]a> puis deleter le a.
Déjeuné avec des français d'une boite sgml parisienne, Monde très ferme sans accès au web ou les dirigeants ont même peur d'un firewall. Le monde SGML a l'air vraiment spécial et fermé, j'ai discuté un peu de CGM mais apparemment les tentatives de rapprochement de CGM et sgml ont échoué, chacun campant sur ces positions, les softs CGM étant incompatibles entre eux, lourds et incroyablement chers.
Norman Walsh, ArborText
Présente un éditeur de stylesheets. Très classique, comme j'en ai vu plein sur les stands, en gros un tree widget displayant la structure du XSL. Comparé à l'expose précèdent, ca craint. Ca poppe des dialogues partout, et on doit se balader sans arrêt dans la hiérarchie.
Créer une règle est un dialogue a 2 fenêtres: une gauche qui matche les flow objects, et une droite qui génère.
Ray Cromwell and Shawn O'Connor, ContentWare
Un hackeur qui vit depuis 4 ans a bidouiller du html en perl pour faire des sites web de boites. Du aux pbs de différences de versions de browser, il a sauté sur XSL des qu'il a pu, et a bricolé un éditeur de XSL pour se faire la main. C'est un éditeur d'arbre a peu près standard, mais avec de bonnes idées, comme un curseur 2D: Si on sélectionne un nœud, il y a une barre rouge sur un des cotes de la boite qui dit ou va s'insérer le prochain objet: avant ou après dans la liste, ou indente ou outdente.
Sinon, c'est en java + JFC ca crashe de folie, et c'est très laid et lourd.
Q d'une formatrice: J'arrive à peu près a comprendre parent, child, mais les technical writers ne s'en sortiront pas de ces outils. Elle plaide pour que les concepteurs d'outils les fassent facile a comprendre.
A: honnêtement, je fais tout sous emacs et je ne me sers pas de ces outils graphiques. Et cet outil vise les designers de stylesheets.
Ramanathan Guha, Netscape
www.mozilla.com
Va regarder le pb de XML pour documents (contrairement aux data, RDF). Le plus dur actuellement pour un usager du web est de trouver ce qu'on veut.
We cannot wait for XSL. So we use CSS, XML-Link.
Il fait sa présentation sur le mozilla qui va être public le 31 mars. Il n'y a plus de html !!! c'est du XML avec des tags book. chapters... Il montre dans son browser des documents que JB avait écrit en XML. Il dit qu'il n'y aura QUE des standards W3C dans mozilla.
On peut inclure des images via XML-Link
La suite du support XML sera faite par la communauté. Soit en tant qu'additions free, soit free stubs pour inclure des additions propriétaires. Seront inclus dans les sources suivantes si les additions sont cross-platform.
Archi : parseur xml (james clark) / DOM + RDF / CSS et XSL
La salle a été unanimement enthousiaste, Des bravos on même été demande (et obtenus) par le public.
Le domaine mozilla et été créé diffèrent de NS pour que vous soyez sur que vos extensions ne tombent pas dans un NS propriétaire.
Il y aura des parties un peu partout pour fêter la sortie de mozilla, voir sur le site pour une près de chez vous!
Tim Bray, Textuality
La spec prête aujourd'hui (4 pages) : www.w3.org/TR/WD-xml-names
europa.eu.int/xml-testfiles : La CEE vient de commencer a faire ses documents officiels en XML!
La communaute SGML ne s'était pas préoccupé des namespaces car c'était une communauté fermée et rigide. Sur le web, il y aura énormément de reuse.
Par exemple en SGML un élément et un attribut ne peuvent avoir le même nom!
on déclare les namespace par une URL (sans #)qui set de déterminant unique (on ne la déreference pas), et d'un préfixe local au document
<?xml:namespace ns="http://foo/bar/gee" prefix="xxx">
puis, usage: <xxx:a xxx:b="yyy">
Le préfixe xml (tous cases) est réservé, ne peut pas être utilise, et on ne peut pas utiliser : dans aucun autre nom (entités)
Un problème potentiel: des DTDs peuvent avoir en elles mêmes des conflits de noms sur les attributs.
Ken Holman, OASIS
OASIS (organisation de bénévoles) s'appelait avant le SGML Open Consortium. Ils ne font pas confiance au w3c ou ISO WG4 pour l'interoperabilite c'est pour cela qui continuent en considérant qu'ils ont prouvé leur capacité a faire coopérer des vendeurs. Ont change de nom pour pouvoir s'attaque au problème de standardisation de CGM, bases de donnes...
Il insiste sur le fait qu'ils ont prouve qu'ils savaient définir, faire respecter et maintenir des specs industrielles. Le problème est complexe. Il avait fait partie de la norme videotexte, des vendeurs cheap faisant un appli crade puis la touillait pour juste passer les tests, mais ne marchait pas ds le monde réel. Une test suite ne suffit pas.
Rohit Khare, IETF:
WebDAV est un outil pour faire de l'édition coopérative de pages web via des extensions HTTP, et des metadata pour décrire les sites et les pages.
Les extension http sont en cours de standardisation a IETF (multiréponse, pour avoir en un coup plusieurs réponses), support de NS, MS, Novell (Bill Jenssen ?)
Protocols CAN be made atop XML! (mais dur a coordonner)
www.ics.uci.edu/~ejw/authoring
futur: il voudrait regarder comment utiliser XMLLinks, XPointers
Mary Holstege, FirstFloor
Utilisent XML comme protocole, interoperabilite, code leverage, formal specs, debug.generation de tests, a l'intérieur d'un serveur java
problèmes: moving targets, efficacité (bandwidth et parsing) (10000 requêtes/jour), entité management
Son expérience c'est que les données sont bien plus grosses que les headers, et que de toutes façons xml se compresse très bien. Mais la mémoire et le temps passe a parser est énorme! le serveur swappe! Car pour la sécurité ils utilisent un parseur validant.
Malheureusement, il faut comprendre XML pour l'utiliser
Il faudrait pouvoir avoir une validation par morceaux, une v. par l'appli, une v. en émission. Par contre avoir un arbre générique ne suffit pas, la DTD est utile. Pour des raisons d'efficacité le mieux est que chaque objet se construise lui-même et vérifie lui-même ses contraintes sinon une verif globale est trop lourde en mémoire.
Ils ont un cache d'entités
Ont séparé l'api en 2 (une commune et une fine) pour diviser la complexité et encourager les usager a utiliser le même subset.
Chaque élément a plusieurs callbacks appelées, plusieurs fois (start, each element last element) pour éviter de consommer trop de mémoire. Une api simple: emitAtrribute et emitElement
Leçons: les developpeurs ne comprendront pas les concepts XML(attributs narrivent pas dans l'ordre : on ne peut pas commencer a parser de suite, good entity management important, turn validation on from day one, generic parse tree are not enough')
Q: efficacité ?
A:2s par requête, mais la plupart du temps est passe dans la database.
Q: performance hit of validation?
A: pas énorme, pas noticeable (ca se sent au départ du serveur au parse de la DTD qui est fait une seule fois). Et ya des optims (hashtables) dans tous les coins
Ray Niemeir, REZsolutions
Vend des technos pour réservation d'hôtel. 56 offices in 38 countries. ~7000 hôtels l'utilisent (hilton...) Historique de plein d'applis ad hoc rigides et dure a interfacer. XML va être une solution pour eux.
gros transaction serveur - 
Ont défini un langage: OBX ,Open booking Exange, en un mélange de DTD et XML-Data. Pas de comment, mais des commentaires dans de vrais éléments qui survivent au parsing.
Ils ont un élément DTD qui contient du texte qui sera interprété ailleurs à partir du texte. "useful trick"
Concept intéressant : BD d'exemples annotés des mots clefs auxquels ils s'appliquent, les listes d'exemples sont générées à partir du contexte.
leçons: perl prototype, java production (10x plus de code a écrire) , et
utilisent DOM comme hashtables de paths => contents
R.T1.#M ==>
V1
R.T3#A.A1 ==> -null-
structure facile a comprendre si on fait l'analogie avec des directories sur un disque.
leçons; ne pas perdre les comments, soigner les exemples, on peut faire de strings, XML se parse bien.
Q: pourquoi pas avoir fait une vraie DTD
A: we were driven by need
Le prochain endroit où on reparlera de XML : la conférence SGML à Paris en Mai 98, et les developpers days en dehors des conferences générales, comme celui de Montréal en Août.
De grands absents dans cette conférence : Apple et les vendeurs Unix autres que SUN.
Une bonne idée : l'organisation de " chat tables " au lieu de BOF (Birds of a feather) : on réserve des tables pour les repas avec des sujets de discussion particuliers, bien que discuter au cours de repas en grande salles est assez difficile vu le niveau sonore.
De fausses idées différentes suivant le background des personnes : certains SGMLers pensent que XML sera un remplaçant de HTML et donc directement displayable par les browsers, certains des bases de données que on va les forcer a utiliser XML comme représentation interne des données dans les bases.
John Bosak a insisté pour qu'on ne demande pas les papiers à l'avance aux speakers : le domaine évoluant si vite, ca n'aurait pas permis de voir les développement les plus récents. Le défaut : des proceedings inexistants...