An overview of the Atom 1.0 Syndication Format

/index.html

  • @rastapopoulos
    RastaPopoulos CC BY-NC
    @stephane

    Question #atom ou plutôt #app pour @stephane :

    Le schéma de base d’une <entry>, au départ c’est calqué sur un système de blog : titre+résumé+auteurs+texte et basta. Pourtant le standard est déjà utilisé pour des applications bien plus complexes (les API Google l’utilisent toutes : ►http://code.google.com/intl/fr/apis/gdata/docs/2.0/basics.html).

    Pourtant, je n’arrive pas à trouver une doc « simple » (pas le #RFC complet quoi) qui explique comment ça se passe dans #AtomPub quand on a plein d’autres champs. Comment ça doit être implémenté ? Il faut ajouter d’autres namespaces avec des schémas en plus, et c’est au serveur de savoir ou pas les gérer ?

    Une appli tierce pourrait renvoyer ça en POST ou PUT :

    <title>Titre de mon objet</title>
    <monappli:champ>Truc</monappli:champ>

    Un serveur classique saura forcément gérer le « title », mais après libre à un serveur de gérer n’importe quel autre élément et/ou attribut en plus ?

    Il n’existe pas encore de #standard pour qu’un serveur déclare les « champs » d’une ressource et que donc un client sache les découvrir ? (Ça serait cool comme standard ! :D )

    RastaPopoulos CC BY-NC
    • @fil
      Fil

      je préconiserais
      <content>
      <div class="chapo">chapo</div>
      <div class="texte">texte</div>
      <div class="ps">ps</div>
      </content>

      ainsi si ton serveur ne connaît pas la subtilité il enregistre toute la structure proprement comme même

      Fil
    • @stephane
      Stéphane Bortzmeyer CC BY-SA

      Cela se nomme un « extension element ». C’est prévu dans Atom (et AtomPub) depuis le début. L’idée est en effet de mettre ces éléments supplémentaires dans un autre espace de noms. Parmi les exemples, des extensions normalisées dans un RFC comme le 4685 ►http://www.bortzmeyer.org/4685.html

      Une bonne explication, avec un exemple simple ("expires"), est donné dans la section « Extending Atom » de ►http://www.ibm.com/developerworks/xml/library/x-atom10/index.html

      Un exemple d’une bibliothèque qui les gère est ratom ►http://ratom.rubyforge.org (voir leurs exemples de code)

      Stéphane Bortzmeyer CC BY-SA
    • @rastapopoulos
      RastaPopoulos CC BY-NC
      @stephane @fil

      @stephane merci beaucoup, je lis ça dès que je me suis reposé.

      Je tiens à redire que ça serait super cool un service standardisé de « découverte de champs » pour un type de ressource. Genre on envoie une requête au serveur APP : dis moi quels sont les champs à utiliser pour les <entry> de la <collection> « patates ». Et hop ça retourne la liste des champs que le serveur sait gérer. :)
      On pourrait faire des clients qui savent alors adapter leurs formulaires (ajouter un champ et son label) dynamiquement !

      @fil c’est intéressant du point de vue du client qui envoie vers un serveur « inconnu » et qui voudrait ne rien perdre, mais je me place surtout dans la position inverse du serveur qui aimerait pouvoir dire « moi je sais gérer tel et tel champ en plus du <content> » (géolocalisation, champs de SPIP en plus, etc). Mais apparemment, pour l’instant, on peut juste écrire de la doc pour décrire les spécificités d’un serveur.

      RastaPopoulos CC BY-NC
    Écrire un commentaire