Mon idée n'était pas de pondre quelque chose de fonctionnel mais de proposer quelque chose pour faire bouger les choses ...
Pour ce qui est du Summary, je ne sais pas si c'est intéressant, car c'est quelque chose qui doit être rempli par l'utilisateur et qu'il ne remplira jamais si il n'a pas la discipline de le faire. En tout cas ce ne dois pas être obligatoire. mais c'est vrai que ca peut être pratique.
les crochets ca peut être pratique pour la langue mais en général quelqu'un ne va pas s'amuser a renseigner un document qu'il crée dans toutes les langues du monde. mais il faut que ce soit permis, c'est vrai.
Pour ce qui est du transfert des méta-données, c'est je pense intéressant de faire soit un conteneur comme je le décris ou d'associer un fichier avec les méta-données. Du moins tant que les protocoles ne permettent pas de spécifier tous les attriuts qu'on veut. Apple le fait déjà avec les données spotlight (je crois, pas testé) qu'il envoie avec chaque fichier attaché dans un email. Un fichier de type application/applefile. Bien sûr je ne sais pas si c'est standardisé. Mon idée c'est de faire quelque chose de similaire standard.
Mais c'est vrai que si tous les protocoles permettent de faire passer les meta-données, ce n'est plus utile du tout.
Pour ce qui est du type de contenu, je ne crois pas qu'il faille garder le content-type actuel qui est assez peu standardisé. Apple propose une alternative basée sur une notation reverse DNS qui permet a n'importe qui de créer des nouveaux types. [http://en.wikipedia.org/wiki/Uniform_Type_Identifier]
Pour ce qui est de la date, je pense que c'est intéressant de la garder. Car il y a trop de cas où elle est perdue. par exemple lorsqu'on compresse/décompresse un fichier, lorsqu'on le copie, ... la date est réinitialisée. Et du coup pas moyen de savoir quand on a bien pu écrire un fichier texte qui traine depuis toujours dans notre homedir.
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Pour ce qui est du Summary, je ne sais pas si c'est intéressant, car c'est quelque chose qui doit être rempli par l'utilisateur et qu'il ne remplira jamais si il n'a pas la discipline de le faire. En tout cas ce ne dois pas être obligatoire. mais c'est vrai que ca peut être pratique.
les crochets ca peut être pratique pour la langue mais en général quelqu'un ne va pas s'amuser a renseigner un document qu'il crée dans toutes les langues du monde. mais il faut que ce soit permis, c'est vrai.
Pour ce qui est du transfert des méta-données, c'est je pense intéressant de faire soit un conteneur comme je le décris ou d'associer un fichier avec les méta-données. Du moins tant que les protocoles ne permettent pas de spécifier tous les attriuts qu'on veut. Apple le fait déjà avec les données spotlight (je crois, pas testé) qu'il envoie avec chaque fichier attaché dans un email. Un fichier de type application/applefile. Bien sûr je ne sais pas si c'est standardisé. Mon idée c'est de faire quelque chose de similaire standard.
Mais c'est vrai que si tous les protocoles permettent de faire passer les meta-données, ce n'est plus utile du tout.
Pour ce qui est du type de contenu, je ne crois pas qu'il faille garder le content-type actuel qui est assez peu standardisé. Apple propose une alternative basée sur une notation reverse DNS qui permet a n'importe qui de créer des nouveaux types. [http://en.wikipedia.org/wiki/Uniform_Type_Identifier]
Pour ce qui est de la date, je pense que c'est intéressant de la garder. Car il y a trop de cas où elle est perdue. par exemple lorsqu'on compresse/décompresse un fichier, lorsqu'on le copie, ... la date est réinitialisée. Et du coup pas moyen de savoir quand on a bien pu écrire un fichier texte qui traine depuis toujours dans notre homedir.