bandeau_edess


Bienvenue, Invité
Nom d'utilisateur: Mot de passe: Se souvenir de moi

SUJET: Homogénéité interne (entre nos messages) et externe (avec UN/CEFACT)

Homogénéité interne (entre nos messages) et externe (avec UN/CEFACT) 15 Mar 2016 11:30 #105

  • Philippe AMELINE
  • Offline
Bonjour,

Si nous prenons l'exemple du type CIDocumentContextParameterType, deux types de problèmes se posent :

1) il est déclaré dans le xsd comme UNECE_RAM_8p0:CIDocumentContextParameterType alors qu'il n'est pas conforme à la définition UN/CEFACT
2) il possède une définition différente au sein de nos messages.

Dans UN/CEFACT, il ressemble à :

0..unbounded CI_ExchangedDocument_Context.BIM_Specified.CI_DocumentContext_Parameter
  • 0..1 CI_DocumentContext_Parameter Identification Identifier
  • 0..1 CI_DocumentContext_Parameter Value Text

  • Donc un bloc O..n de paramètres définis par l'identifiant du paramètre et la valeur donnée à ce paramètre.

    Avantage (en dehors de la conformité) : pour ajouter un paramètre, il suffit d'ajouter une ligne à la liste des identifiants et il n'est pas nécessaire de modifier le xsd (c'est d'ailleurs exactement cette mécanique que nous avons mise en oeuvre pour ajouter des paramètres "locaux" au bénéficiaire avec la balise AdditionnalInformation).

    Inconvénient : on ne peut pas contrôler le type précis des paramètres, qui sont tous de type Text, alors qu'on souhaite décrire des dates ou, pire, comme dans Delivery, des codes pris au sein d'une liste.

    A mon sens, il serait difficile de revenir en arrière et nos messages ont désormais un bloc CIDocumentContextParameterType qui contient des balises explicites... mais alors, il n'a plus de raison d'être de cardinalité 0..n et devrait être 0..1

    Par ailleurs, nous avons un problème d'homogénéité interne car :

    Dans Order :

    <xsd:complexType name="CIDocumentContextParameterType">
    _<xsd:sequence>
    __<xsd:element name="CommitteeDateTime" type="DateMandatoryDateTimeType" minOccurs="0"/>
    _</xsd:sequence>
    </xsd:complexType>

    Dans Delivery :

    <xsd:complexType name="CIDocumentContextParameterType">
    _<xsd:sequence>
    __<xsd:element name="ID" type="CodeQualifiedType"/>
    __<xsd:element name="ReasonForAbsence" type="TextType"/>
    __<xsd:element name="NaturePrestation" type="CodeQualifiedType" minOccurs="0"/>
    _</xsd:sequence>
    </xsd:complexType>

    Dans Invoice :

    <xsd:complexType name="CIDocumentContextParameterType">
    _<xsd:sequence>
    __<xsd:element name="ID" type="IDType_Qualified" minOccurs="0"/>
    _</xsd:sequence>
    </xsd:complexType>

    Le même type déclaré dans chaque xsd comme UNECE_RAM_8p0:CIDocumentContextParameterType a donc trois implémentations locales distinctes, ce qui me paraît très préjudiciable.

    Je propose de conserver à Order (dont nous avons publié la 1.0) le type CIDocumentContextParameterType et de créer dans Delivery et Invoice des types spécifiques (par exemple CIDeliveryDocumentContextParameterType et CIInvoiceDocumentContextParameterType).

    Je vous remercie d'avance d'exprimer votre opinion sur ce sujet qu'il faut "déminer" d'urgence.
    L'administrateur à désactivé l'accès en écriture pour le public.
    Propulsé par Forum Kunena