Marwan KHELIF » XML

HTML 5 : deux nouveaux documents

mkhelif — Wed, 18 Feb 2009 13:57:34 +0000

Le W3C (World Wide Web Consortium, consortium chargé de promouvoir la compatibilité des technologies Web) vient de publier deux nouveaux documents traitant de la version 5 de HTML. La version 4 de HTML a été figée en 1997 et la version 5 est en développement depuis 2004.

L’un des documents présente la liste des différences entre HTML 4 et HTML 5 (liste évidement non exhaustive) :

Le langage est basé sur l’utilisation des documents DOM.
Concept de contextes de navigation.
Nouveaux concepts de modèles de contenu (remplaçant les actuels block et inline).
Nouveaux éléments : datagrid, menu (pour l’utilisation en natif de menu contextuel), commands.
Gestion du cache pour les applications Web en mode déconnecté (concept de Google Gears?).
Concept de UndoManager, permettant de gérer l’undo/redo.
Architecture de copier/coller et drag&drop.
Nouveaux éléments permettant d’embarquer du contenu vidéo, canvas (pour les graphes 2D, les jeux, …).
Nouveaux types d’élément input : date, number, email, url, color, …L’élément input a aussi droit à un nouvel attribut : autofocus, permettant de lui donner directement le focus lors du chargement de la page.
Suppression des éléménts frame, frameset et noframe, car ils dégradent l’utilisation et l’accessibilité du site.

HTML 5 sera évidement compatible avec les pages en HTML 4. Cette nouvelle version a aussi pour but de standardiser toutes les API JavaScript grâce à un référentiel commun.

L’autre document est la spécification complète de HTML 5.

Pour suivre votre lecture

Java : Utilisation de Protocol Buffers

mkhelif — Tue, 29 Jul 2008 09:34:21 +0000

Voici un petit tutoriel sur l’utilisation du nouveau format de Google : Protocol Buffers en Java. Ce format se veut être le remplaçant de XML, standard actuel pour le stockage et l’échange de données au format texte.

Dans cet exemple nous allons créer un gestionnaire de contact. Ce billet est une traduction de la documentation de Google : Protocol Buffers Basics.

Fichier de définition

Tout d’abord le fichier de définition .proto permettant de définir le format des données.

package fr.mkhelif.pb;
 
option java_package = "fr.mkhelif.pb.demo";
option java_outer_classname = "AddressBook";
 
message Contact {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;
 
  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }
 
  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }
 
  repeated PhoneNumber phone = 4;
}
 
message AddressBook {
  repeated Contact contact = 1;
}

La déclaration d’un package permet comme en Java d’éviter les conflits de nom. Si vous déclarez un package (comme dans cet exemple) le package de la classe Java sera le même. Ici on surcharge le package java avec l’option java_package. On définie le nom de la classe Java grâce à l’option java_outer_classname. Si vous ne définissez pas de nom de classe le compileur utilisera le nom du fichier : adressbook.proto donnera AdressBook. Ensuite on définie un bean, appelé ici message, Personne avec des attributs name, id, email et phone. Comme dans les langages objets, un message (bean) est défini par des attributs. Ici une personne possède un nom (name), un identifiant (id), une adresse email et plusieurs numéros de téléphone (phone). Un attribut est soit un autre message soit un type simple : string, int32, boolean, float ou double. Vous pouvez aussi définir des énumérations permettant ainsi de limiter le nombre d’élément possibles (dans l’exemple précédent un numéro de téléphone possède un type qui ne peut être que : MOBILE, HOME ou WORK. Chaque champs doit être annoté d’un des modifieurs suivants :

required : le champs est obligatoire. Si il n’est pas initialisé l’objet est marqué comme uninitialized. Lors de la sérialisation d’un objet uninitialized une RuntimeException est levée. Lors de la déserialisation une IOException est levée.
optional : le champs est optionnel et peut ne pas être initialisé. Un message avec un champs optional non initialisé utilisera une valeur par défaut : 0 pour les types numériques, false pour les boolean, une chaîne vide pour les string et pour les messages une instance par défaut avec tous les champs avec des valeurs par défaut. Vous pouvez spécifier une valeur par défaut pour un champs : [default = ] comme pour le type de numéro de téléphone.
repeated : le champs peut être répétés 0 ou plusieurs fois. L’ordre des valeurs est respecté lors de la (dé)sérialisation. Un champs répété agit comme un tableau dynamique.

Les marqueurs « =1″, « =2″, …permettent d’identifier le tag unique utilisé par ce champs lors de la sérialisation. Les marqueurs de 1 à 15 sont encodés sur un octet de moins que les marqueurs supérieurs à 16. Ainsi les marqueurs de 1 à 15 peuvent être utilisés par les champs souvent utilisés ou par les champs repeated.

Compilation de votre ProtocolBuffers

Pour compiler le fichier .proto en classes il suffit d’utiliser le compilateur de ProtocolBuffers : protoc.

En exécutant la commande suivante le compilateur va générer une classe AddressBookProtos.java avec des classes internes :

protoc AddressBook.proto –java_out=

Dans le répertoire il va y avoir l’arborescense : /fr/mkhelif/pb/AddressBookProtos.java

Utilisation des classes

Création d’un objet

Pour créer un object Contact il faut utiliser la classe : Contact.Builder qui permet d’instancier un objet valide.

Contact.Builder contact = Contact.newBuilder ();
contact.setName ("Marwan KHELIF");
contact.setEmail ("contact@mkhelif.fr");
 
Contact.PhoneNumber phone = Contact.PhoneNumber.newBuilder ();
phone.setNumber ("0123456789");
phone.setType (Contact.PhoneType.HOME);
 
contact.addPhone (phone);
contact.build ();

L’utilisation de ProtocolBuffers permet de chaîner les appels de méthodes, ainsi l’exemple précédent peut être écris :

Contact.Builder contact = Contact.newBuilder ();
contact.setName ("Marwan KHELIF")
    .setEmail ("contact@mkhelif.fr")
    .addPhone (Contact.PhoneNumber.newBuilder ()
        .setNumber ("0123456789")
        .setType (Contact.PhoneType.HOME).build ())
    .build ();

Sérialisation des objets

Afin de sérialiser un objet il y à deux méthodes :

Récupérer directement un tableau d’octets : toByteArray ().
Sérialiser directement dans un flux : writeTo (OutputStream).

De même pour la déserialisation :

Depuis un tableau d’octets : parseFrom (byte[]).
Depuis un flux : parseFrom (InputStream).

Amélioration

Par défaut le compilateur de ProtocolBuffers génère des fichiers le plus petits possible. Si dans votre applications vous avez des problèmes de performances dues aux classes générées, vous pouvez ajouter l’option :

1	option optimize_for = SPEED;

Cette option permet de compiler des fichiers plus gros mais à l’exécution le code sera optimizé pour votre ProtocolBuffer.

Conclusion

Ce nouveau format est très prometteur car la définition des fichiers proto est beaucoup plus orientée objet que XML. Cependant il reste encore des points à améliorer.

Pour suivre votre lecture

Google lance Protocol Buffers

mkhelif — Thu, 10 Jul 2008 16:17:57 +0000

Vous pensiez que XML était un standard, Google veut changer la donne avec un nouveau format : Protocol Buffers.

Google annonce ce nouveau format : « Pensez à XML mais en plus petit, plus rapide et plus simple ». Ce format est utilisé depuis longtemps par Google dans ses applications. Le principe de ce format ressemble à une sérialisation des données : on définie la structure des données, on compile pour obtenir du code source permettant de lire et écrire.

Actuellement ce format est développé uniquement en C++, Java et Python. Le langage Perl est déjà prévu mais rien pour PHP, Ruby, DotNet.

Ce nouveau format ne changera pour l’instant pas le standard qu’est XML. Mais si ce dernier n’évolue pas, surtout au niveau de la rapidité, il se pourrait bien que Protocol Buffers prenne sa place.

Pour suivre votre lecture

Validation XML

mkhelif — Thu, 03 Jan 2008 10:21:52 +0000

Lors de l’utilisation du langage XML on voudrait que tous les documents que l’on va parser soit valide, c’est à dire qu’ils correspondent à un certain format. Cependant si l’utilisateur a accés à ces documents XML il faut pouvoir vérifier que le document est valide.
On peut réaliser cette vérification pendant le parsing mais cela ajoute une tâche au développeur.

C’est pour cela qu’il existe des langages de validations, ils permettent de valider le format des documents XML selon un format qui est défini par le dévéloppeur.

La plupart des parseurs vérifient le format et renvoient une erreur si le format n’est pas respecté.

Les langages de validations

Il existe plusieurs langages de validations, mais je ne vais vous présenter que les deux les plus utilisés.

Les différents langages :

DTD (Document Type Definition) : définition du type de document. Ce langage peut être inclu directement dans le document XML.
XML Schema : il permet de définir la structure d’un document avec plus de précision (type de donnée, nombre d’occurence, …).
Relax NG (REgular LAnguage for XML Next Generation) : ce langage ne spécifie que la structure du document, le type de donnée est sous-traitée à la bibliothèque de types de XML Schema.
Schematron : contrairement aux autres langages Schematron définie un modèle d’arbre du document XML, il utilise la même conception que XPath ou XSLT.

Doctype

Une DTD est une grammaire permettant de vérifier la validité d’un document.
Un document XML peut avoir une DTD incluse dans son entête ou bien indiquée le fichier où elle se situe.

Une DTD définit trois objets permettant de définir la grammaire :

ELEMENT : représente un élément XML et permet de définir les sous-éléments ansi que leurs occurences.
ATTLIST : liste des attributs d’un élément.
ENTITY : permet de définir un ‘alias’.

Une DTD est définie de la façon suivante :

]>

Voici un site permettant de valider un fichier XML avec sa DTD : http://www.stg.brown.edu/service/xmlvalid/.

Élément

Permet de définir un élément XML en spécifiant le nom les sous-éléments de ce dernier.
La déclaration d’un ENTITY doit avoir la syntaxe suivante :

La définition des Donnees peut avoir les valeurs suivantes :

(#PCDATA) : l’élément contient des données de types textes mais ne peut pas contenir de sous-éléments.
(Element1, Element2, …) : liste des sous-éléments que contient l’élément.
(Element1 | Element2 | …) : liste des sous-éléments qui peuvent être contenus par cet élément.
ANY : cet élément peut contenir n’importe quel type de données.
EMPTY : cet élément doit être vide et ne peux contenir aucune donnée (texte ou éléments).

Dans la définition des sous-éléments on peut spécifier l’occurence de l’élément :

Element1? : l’élément peut apparaître 0 ou 1 fois.
Element1+ : l’élément peut apparaître 1 ou plusieurs fois.
Element1* : l’élément peut apparaître 0, 1 ou plusieurs fois.

On peut spécifier le nombre de sous-élément en répétant l’élément enfant :

Ici l’ « élément1″ devra forcément contenir 2 éléments « element2″.

Voici un exemple de DTD d’une liste de contacts :

]>


  
    Marwan KHELIF
      ...
      mkhelif@gmail.com
    
  
      My Name
      My address
      my.mail@mail.com

Attlist

La déclaration ATTLIST permet de définir les attributs d’un élément. On peut spécifier le type de donnée, la valeur par défaut, forcer la présence de l’élément, …

La déclaration se fait ainsi :

Le nom de l’élément doit correspondre au nom d’un élément déclaré dans la DTD.

Le type de l’attribut peut prendre les valeurs suivantes :

CDATA : l’attribut contient des données textuelles.
ID : chaqu’un des éléments définis doit avoir une valeur différente pour cet attribut.
IDREF : référence la valeur d’un attribut ID d’un autre élémént.
IDREFS : liste d’attributs ID, ses valeurs sont séparées par un espace.
ENTITY : correspond à une ENTITY déclarée dans la DTD.
ENTITIES : listes d’ENTITY déclarées dans la DTD, chaque ENTITY doit être séparées par un espace.
NMTOKEN : la valeur doit être un nom XML valide.
NMTOKENS : liste de noms XML valides.
NOTATION : nom d’une notation définie dans la DTD.

La valeur par défaut de l’attribut peut prendre les valeurs suivantes :

valeur : valeur par défaut de l’attribut.
#REQUIRED : l’élément doit forcément posséder cet attribut.
#IMPLIED : cet attribut n’est pas obligatoire.
#FIXED valeur : l’attribut doit forcément avoir la valeur valeur.

Voilà un exemple de DTD définissant des attributs :

]>


  
    ...
    mkhelif@gmail.com
  
  
    ...
    monMail@mail.com

Entity

La déclaration d’une ENTITY permet de créer un ‘alias’, elle est ensuite utilisable dans le document XML.

On la déclare de la façon suivante :

On peut alors l’utiliser dans le document XML : &nomEntity;, la valeur définie sera alors positionnée à la place de cet entité.

Par exemple :

]>


  Presentation de &dtd; par &auteur;.
  Presentation de &xsd; par &auteur;.

Ce sont les entités générales du document, il y a un autre type d’entités : les entités paramètes.
Elles sont définies de la même manière sauf qu’il faut rajouter un ‘%‘ devant le nom :

On les utilise de la façon suivante : %nomEntity;.
Voilà un exemple de leur utilisation :

]>


  
    &dtd;
    &auteur;
    17/07/07
    Presentation de &dtd; par &auteur;.
  
  
    &xsd;
    &auteur;
    17/07/07
    Presentation de &xsd; par &auteur;.

Ces deux types d’entités sont internes au document XML, on peut indiquer que la cible de l’entité est un fichier externe au document :


&doc;

%articles;

Lors de l’utilisation de l’entité le contenu du fichier sera chargé et remplacera l’entité.