You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reprise des éléments reçu par mail pour suivre la bonne prise en compte dans le profil France. quelques formulations et mises en formes sont modifiées pour permettre l'affichage sur Github.
Mail initial du 29/11/2024
Partie 6.4.2
Dans l’exemple nous avons :
<FareDemandFactorversion="any"id="tfl:offPeak">
<Name>off peak time travel</Name>
<Description>Has stop specific overrides</Description>
Or dans la table, nous n’avons pas de champs « Description » :
C’est un héritage de QualityStructureFactor :
Lui-même héritant de :
Sur ce point, deux questionnements :
L’ordre des tables n’est pas pratique, pourrions-nous réfléchir à la mise en place de liens hypertextes dans « Type » ?
On constate que les identifiants sont présents dans toutes les tables alors qu’il doit s’agir d’un héritage et donc ne devrait pas être répété ?
Point 2
Pour revenir sur le sujet des DistanceMatrixElement, de mon point de vue, il s'agit non pas de distances, mais d'indices. De plus, dans le cadre des O/D, qu'est-ce qui justifie l'appellation de matrice puisque nous ne définissons qu'une O/D à la fois ?
Mail du 12/12/2024
Pour la durée de correspondance, nous pouvons lire dans la partie 6.7.1. Résumé Des Conditions Tarifaires :
Un RÉSUMÉ DES CONDITIONS TARIFAIRES (CONDITION SUMMARY) peut être utilisé pour fournir une description synthétique d’un produit à des fins de comparaison et d’information des voyageurs. Le résumé indique généralement simplement l’existence d’une condition - les conditions réelles elles-mêmes sont décrites plus exactement par les CONDITIONS D’UTILISATION, les AFFECTATIONS DE DROITS D’ACCÈS et d’autres éléments. Le résumé peut inclure des informations sur :
• Les exigences concernant les cartes liées au produit.
• Les conditions commerciales de remboursement, d’échange, etc.
• Conditions limitant les temps de parcours, les itinéraires, etc.
• Conditions relatives aux droits.
• Conditions affectant la réservation.
Nous pourrions penser que ConditionSummaryTravelGroup répond au besoin, mais je n'ai trouvé aucune balise décrivant la durée de correspondance. En revanche, dans la partie « 6.10 Conditions d’utilisation » :
[…]
Les CONDITIONS D’UTILISATION DU VOYAGE spécifient les limites de voyage telles que ALLER-RETOUR, ITINÉRAIRE, FRÉQUENCE D’UTILISATION, ÉCHANGE, PÉRIODE DE VALIDITÉ D’UTILISATION, SÉJOUR MINIMUM.
La partie en gras ci-dessus ne semble pas nécessaire puisque ces conditions sont répétées ci-dessous (de même pour d’autres parties du document) :
Remarque : Je ne pense pas que la partie surlignée en jaune soit nécessaire, puisque ces conditions sont répétées ci-dessous : (De même pour d’autres parties du document)
• ALLER-RETOUR exprimant les propriétés relatives à l’utilisation d’aller simple ou d’aller-retour d’un droit d’accès.
• PÉRIODE DE VALIDITÉ D’UTILISATION décrit une limitation dans le temps des droits d’accès, en particulier des abonnements. Il peut inclure une « durée standard » de validité (1 jour, 1 mois…), des limites de temps (« date de début » et « date de fin », « heure de début » et « heure de fin »), ou une combinaison des deux ;
• FRÉQUENCE D’UTILISATION décrit la limitation d’un droit d’accès, en fonction de la fréquence d’utilisation pendant une PÉRIODE DE VALIDITÉ. Par exemple, un produit est proposé à un tarif spécial s’il est utilisé plus de 50 fois par mois ;
• CORRESPONDANCE exprimant les limites de correspondances au cours d’un voyage ;
• SÉJOUR MINIMUM, exprimant les détails de tout séjour minimum à destination requis pour utiliser le produit (typiquement une réduction si l’on passe un weekend sur place) ;
• LIMITE DE SEUIL, paramètre géographique limitant les droits d’accès par comptage d’arrêts, tronçons ou zones ;
• ITINERAIRE, expression des limitations lié à l’itinéraire suivi, pour un droit d’accès ;
• SUPENSION, décrivant les conditions applicables pour suspendre temporairement un droit d’accès tel qu’un abonnement.
[…]
On retrouve :
« CORRESPONDANCE exprimant les limites de correspondances au cours d’un voyage »
Il est écrit plus bas :
« Les figures ci-dessous présente les modèles de données pour l’ensemble des conditions d’utilisation. Ces conditions sont à prendre tel-quel et > il n’y a pas de véritable intérêt à leur applique un travail de profil, les tableaux d’attributs qui leur correspondent on don été placés en annexe (en > anglais) pour référence (ceci afin de ne pas surcharger inutilement la partie principale de ce document) »
Remarque : les conditions d'utilisation me semblent trop importantes pour que les tableaux d'attributs soient déposés en annexe. De manière générale, dans les documents, on retrouve des exemples, des tableaux d'informations, des résultats d'analyses, etc. Ici ces informations sont indispensables tant pour la billettique que pour les médias, elles seront donc nécessairement lues par l'ensemble des utilisateurs de cette norme. Les intégrer dans le corps du document offre donc plus de clarté pour la structure et la logique du document, d'autant que les UML correspondants sont dans le corps.
En revanches, je suis en phase avec le fait qu’« il n’y a pas de véritable intérêt à leur appliquer un travail de profil ».
Puis dans l’annexe « A.1.4 Interchanging – Element »
Table 112, on a la balise : MaximumTimeToMakeATransfer qui est la durée de correspondance.
The text was updated successfully, but these errors were encountered:
Reprise de la réponse de @TuThoThai (hors sujet des typos traité par ailleurs) :
Pour les correspondances, je vois deux sujets
Une clarification des différences entre CONDITIONS TARIFAIRES et CONDITIONS D’UTILISATION : à vue de nez, le premier est pour moi l’équivalent les CGV alors que le second est lié au tarif en soi. Et donc j’y mettrai effectivement les correspondances
Une demande d’accord de travailler ensemble la représentation du titre de Guéret pour que cela fasse partie des illustrations du profil France. Au même titre que nous avons acté la tarification zonale du SMT AML avec Colibri et celle multimodale de BreizhGO + Star 1
Reprise des éléments reçu par mail pour suivre la bonne prise en compte dans le profil France. quelques formulations et mises en formes sont modifiées pour permettre l'affichage sur Github.
Mail initial du 29/11/2024
Partie 6.4.2
Dans l’exemple nous avons :
Or dans la table, nous n’avons pas de champs « Description » :
C’est un héritage de QualityStructureFactor :
Lui-même héritant de :
Sur ce point, deux questionnements :
Point 2
Pour revenir sur le sujet des DistanceMatrixElement, de mon point de vue, il s'agit non pas de distances, mais d'indices. De plus, dans le cadre des O/D, qu'est-ce qui justifie l'appellation de matrice puisque nous ne définissons qu'une O/D à la fois ?
Mail du 12/12/2024
Pour la durée de correspondance, nous pouvons lire dans la partie 6.7.1. Résumé Des Conditions Tarifaires :
Nous pourrions penser que ConditionSummaryTravelGroup répond au besoin, mais je n'ai trouvé aucune balise décrivant la durée de correspondance. En revanche, dans la partie « 6.10 Conditions d’utilisation » :
La partie en gras ci-dessus ne semble pas nécessaire puisque ces conditions sont répétées ci-dessous (de même pour d’autres parties du document) :
On retrouve :
Il est écrit plus bas :
Remarque : les conditions d'utilisation me semblent trop importantes pour que les tableaux d'attributs soient déposés en annexe. De manière générale, dans les documents, on retrouve des exemples, des tableaux d'informations, des résultats d'analyses, etc. Ici ces informations sont indispensables tant pour la billettique que pour les médias, elles seront donc nécessairement lues par l'ensemble des utilisateurs de cette norme. Les intégrer dans le corps du document offre donc plus de clarté pour la structure et la logique du document, d'autant que les UML correspondants sont dans le corps.
En revanches, je suis en phase avec le fait qu’« il n’y a pas de véritable intérêt à leur appliquer un travail de profil ».
Puis dans l’annexe « A.1.4 Interchanging – Element »
Table 112, on a la balise : MaximumTimeToMakeATransfer qui est la durée de correspondance.
The text was updated successfully, but these errors were encountered: