OASIS Universal Business Language (UBL) TC

 View Only
Expand all | Collapse all

Newly detected backward compatibility error - TransportContract

Tim McGrath

Tim McGrath07-24-2010 06:45

  • 1.  Newly detected backward compatibility error - TransportContract

    Posted 07-19-2010 02:03
    Hi folks,
    
    It turns out our decision to accept new dictionary entry names for 
    old constructs was hiding a backwards compatibility 
    problem.  Thankfully the sample instances revealed the need to update 
    the model checking.  And thankfully that updated model checking found 
    only the one problem revealed by the sample instances and not any 
    other problems of the same ilk.
    
    Far below is the latest complete report and excerpted here below is 
    the new addition:
    
    ASBIEs found in error: 1
    Old Parent DEN: "Consignment. Details"
    New Parent DEN: "Consignment. Details"
    Old name: "TransportContract"
    New name: "TransportContract"
    Old DEN: "Consignment. Transport_ Contract. Contract"
    New DEN: "Consignment. Transport Contract"
    Old associated class: "Contract"
    New associated class: "Transport Contract"
       Old order:
        1 ID
       *2 IssueDate
       *3 IssueTime
       *4 ContractTypeCode
       *5 ContractType
       *6 ValidityPeriod
       *7 ContractDocumentReference
    
       New order (not including newly-introduced optional constructs):
    
       New order (all constructs):
        1 Contract
       *2 NominationPeriod
       *3 ContractualDelivery
    
    
    What this means is that until this is fixed UBL 2.1 is not backward 
    compatible to UBL 2.0 because UBL 2.0 is expecting:
    
       


  • 2.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-22-2010 12:24
    Based on a question from Andy, I have thought of another option (D):
    
    (D) - we leave Consignment. Transport_ Contract. 
    Contract as it is without changing it
      - we keep the new Transport Execution Plan. 
    Transport Contract as it has been proposed without changing it
      - we change our presumption that two different 
    ASBIEs cannot have the same UBL name
    
    There is a partial precedent for this in that we 
    already have a conflict in UBL local names with 
    both an ASBIE and a BBIE named "Location", but 
    because they are in different namespaces this 
    isn't a challenge for a programmer basing their 
    logic on the namespace-qualified UBL name: 
    


  • 3.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-22-2010 14:28
    Hello,
    
    I have a business question on this topic.
    
    For which reason we are going to use a specific "Transport Contract" class
    over the generic "Contract" class ?
    
    From the information below I do not see a valid reason.  I mean the
    following information seems to me still related to *any* contract and
    sub-contract.
    
    So I would see a more simple solution where we just update the actual
    cac:Contract by adding "NominationPeriod" and "ContractualDelivery" at the
    end of its structure.
    
    Moreover I would suggest to add a Sub-Contract (0..n) too.
    
    New Draft Contract:
    
    - ID
    - IssueDate
    - IssueTime
    - ContractTypeCode
    - ContractType
    - ValidityPeriod
    - ContractDocumentReference
    - NominationPeriod
    - ContractualDelivery
    - SubContracts
      - Contract (0..n)
    
    
    Hope this helps...
    
    Roberto
    
    
    > Based on a question from Andy, I have thought of another option (D):
    >
    > (D) - we leave Consignment. Transport_ Contract.
    > Contract as it is without changing it
    >   - we keep the new Transport Execution Plan.
    > Transport Contract as it has been proposed without changing it
    >   - we change our presumption that two different
    > ASBIEs cannot have the same UBL name
    >
    > There is a partial precedent for this in that we
    > already have a conflict in UBL local names with
    > both an ASBIE and a BBIE named "Location", but
    > because they are in different namespaces this
    > isn't a challenge for a programmer basing their
    > logic on the namespace-qualified UBL name:
    > 


  • 4.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-22-2010 14:35
    At 2010-07-22 16:27 +0200, Roberto Cisternino wrote:
    >I have a business question on this topic.
    >
    >For which reason we are going to use a specific "Transport Contract" class
    >over the generic "Contract" class ?
    
    Yes, the answer to that is critical to the direction we choose to take.
    
    > From the information below I do not see a valid reason.  I mean the
    >following information seems to me still related to *any* contract and
    >sub-contract.
    >
    >So I would see a more simple solution where we just update the actual
    >cac:Contract by adding "NominationPeriod" and "ContractualDelivery" at the
    >end of its structure.
    
    Yes, this is my proposed solution (A) to this problem.  All the more 
    reason if they are not specific to transportation as I was worried they were.
    
    A note to the TSC:  the existing Contract has only optional 
    constructs so it would seem that (A) would meet your users needs by 
    leaving the "old" constructs absent and only using the new constructs 
    you have defined.
    
    >Moreover I would suggest to add a Sub-Contract (0..n) too.
    
    Can we please leave that question to the response to PRD01?  I know 
    it is a simple change but at this (very!) late stage to prepare PRD01 
    for review I would like to restrict discussions only to things that 
    at this moment are broken or unresolved.
    
    . . . . . . . . . . . Ken
    
    > > At 2010-07-18 22:02 -0400, I wrote:
    > >>


  • 5.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-22-2010 14:42
    Ok Ken,
    
    forget sub-contracts now, also it is not viable as this addition would
    require a party too.
    
    I vote for (A) as nomination and delivery date are common concepts to
    transportation, constructions, ...
    
    I really prefere we enhance the actual base Contract for these new info.
    
    Roberto
    
    > At 2010-07-22 16:27 +0200, Roberto Cisternino wrote:
    >>I have a business question on this topic.
    >>
    >>For which reason we are going to use a specific "Transport Contract"
    >> class
    >>over the generic "Contract" class ?
    >
    > Yes, the answer to that is critical to the direction we choose to take.
    >
    >> From the information below I do not see a valid reason.  I mean the
    >>following information seems to me still related to *any* contract and
    >>sub-contract.
    >>
    >>So I would see a more simple solution where we just update the actual
    >>cac:Contract by adding "NominationPeriod" and "ContractualDelivery" at
    >> the
    >>end of its structure.
    >
    > Yes, this is my proposed solution (A) to this problem.  All the more
    > reason if they are not specific to transportation as I was worried they
    > were.
    >
    > A note to the TSC:  the existing Contract has only optional
    > constructs so it would seem that (A) would meet your users needs by
    > leaving the "old" constructs absent and only using the new constructs
    > you have defined.
    >
    >>Moreover I would suggest to add a Sub-Contract (0..n) too.
    >
    > Can we please leave that question to the response to PRD01?  I know
    > it is a simple change but at this (very!) late stage to prepare PRD01
    > for review I would like to restrict discussions only to things that
    > at this moment are broken or unresolved.
    >
    > . . . . . . . . . . . Ken
    >
    >> > At 2010-07-18 22:02 -0400, I wrote:
    >> >>


  • 6.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-23-2010 13:50
    Hi Ken,
    
    I analized your proposals and my opinion is as follows: I don't like 
    solutions B and D, because of the problems that you described.
    
     From my point of view A solution is the best, so I agree with 
    Roberto, but I think also that the C solution could be acceptable.
    
    I am going to wait for your final decision before to act.
    
    Best regards
    
    Arianna
    
    
    
    il Thu, 22 Jul 2010 16:40:46 +0200 (CEST)
      "Roberto Cisternino" 


  • 7.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-23-2010 13:56
    Hello Arianna,
    
    I'm leaning toward solution A also, but with no real understanding
    of why the new items were felt to be necessary.
    
    As decided in this week's Atlantic TC call, however, the decision
    will be made by the UBL Transport Subcommittee (TSC).  We are
    expecting that decision at next week's meeting.
    
    Jon
    
    Arianna Brutti wrote:
    > Hi Ken,
    > 
    > I analized your proposals and my opinion is as follows: I don't like 
    > solutions B and D, because of the problems that you described.
    > 
    >  From my point of view A solution is the best, so I agree with Roberto, 
    > but I think also that the C solution could be acceptable.
    > 
    > I am going to wait for your final decision before to act.
    > 
    > Best regards
    > 
    > Arianna
    > 
    > 
    > 
    > il Thu, 22 Jul 2010 16:40:46 +0200 (CEST)
    >  "Roberto Cisternino" 


  • 8.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-27-2010 07:56
    
    
      
      
    
    
    Hi Ken,

    according to the last decision of TSC, I implemented the option (A).

    So, to summarize now we have:

    Consignment. Transport_ Contract. Contract

    where "Contract" class is as follows:
       1 ID
       2 IssueDate
       3 IssueTime
       4 ContractTypeCode
       5 ContractType
     *6 Note
       7 ValidityPeriod
       8 ContractDocumentReference  
    * 9 NominationPeriod
    *10 ContractualDelivery

    (*added in UBL 2.1)

    The definitions related to ASBIE 9 and 10 are:

    NominationPeriod: An association to Period. The nomination period is the period in which the transport user has to book the transport service before the transport should begin.

    ContractualDelivery: An association to Delivery.

    I am asking if these definitions should be modified in order to specify that these ASBIEs should be used only in transport context.

    Best regards

    Arianna


    Il 23/07/2010 15:55, Jon Bosak ha scritto:
    4C499F5C.9000702@pinax.com" type="cite">Hello Arianna,

    I'm leaning toward solution A also, but with no real understanding
    of why the new items were felt to be necessary.

    As decided in this week's Atlantic TC call, however, the decision
    will be made by the UBL Transport Subcommittee (TSC).  We are
    expecting that decision at next week's meeting.

    Jon

    Arianna Brutti wrote:
    Hi Ken,

    I analized your proposals and my opinion is as follows: I don't like solutions B and D, because of the problems that you described.

     From my point of view A solution is the best, so I agree with Roberto, but I think also that the C solution could be acceptable.

    I am going to wait for your final decision before to act.

    Best regards

    Arianna



    il Thu, 22 Jul 2010 16:40:46 +0200 (CEST)
     "Roberto Cisternino" <roberto@javest.com> ha scritto:
    Ok Ken,

    forget sub-contracts now, also it is not viable as this addition would
    require a party too.

    I vote for (A) as nomination and delivery date are common concepts to
    transportation, constructions, ...

    I really prefere we enhance the actual base Contract for these new info.

    Roberto

    At 2010-07-22 16:27 +0200, Roberto Cisternino wrote:
    I have a business question on this topic.

    For which reason we are going to use a specific "Transport Contract"
    class
    over the generic "Contract" class ?

    Yes, the answer to that is critical to the direction we choose to take.

    From the information below I do not see a valid reason.  I mean the
    following information seems to me still related to *any* contract and
    sub-contract.

    So I would see a more simple solution where we just update the actual
    cac:Contract by adding "NominationPeriod" and "ContractualDelivery" at
    the
    end of its structure.

    Yes, this is my proposed solution (A) to this problem.  All the more
    reason if they are not specific to transportation as I was worried they
    were.

    A note to the TSC:  the existing Contract has only optional
    constructs so it would seem that (A) would meet your users needs by
    leaving the "old" constructs absent and only using the new constructs
    you have defined.

    Moreover I would suggest to add a Sub-Contract (0..n) too.

    Can we please leave that question to the response to PRD01?  I know
    it is a simple change but at this (very!) late stage to prepare PRD01
    for review I would like to restrict discussions only to things that
    at this moment are broken or unresolved.

    . . . . . . . . . . . Ken

    > At 2010-07-18 22:02 -0400, I wrote:
    >><cac:TransportContract> is obliged to contain at
    >>least the old children, but it is allowed to
    >>have new optional children.  I see three ways to fix this:
    >>
    >>(A) We could add the new items to the old
    >><Contract> but they aren't related to contracts
    >>in general, only to transportation
    >>contracts.  But that isn't so bad since users
    >>are already used to finding things in objects that they don't need.



    -- 
    XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
    Vote for your XML training:   http://www.CraneSoftwrights.com/m/i/
    Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
    G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
    Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/m/bc
    Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




    -- 
    * JAVEST by Roberto Cisternino
    *
    * Document Engineering Services Ltd. - Alliance Member
    * UBL Italian Localization SubCommittee (ITLSC), co-Chair
    * UBL Online Community editorial board member (ubl.xml.org)
    * Italian UBL Advisor

     Roberto Cisternino

     mobile: +39 328 2148123 begin_of_the_skype_highlighting              +39
    328 2148123      end_of_the_skype_highlighting
     skype:  roberto.cisternino.ubl-itlsc

    [UBL Technical Committee]
       http://www.oasis-open.org/committees/ubl

    [UBL Online Community]
       http://ubl.xml.org

    [UBL International Conferences]
       http://www.ublconference.org

    [UBL Italian Localization Subcommittee]
       http://www.oasis-open.org/committees/ubl-itlsc

    [Iniziativa divulgativa UBL Italia]
       http://www.ubl-italia.org



    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.839 / Virus Database: 271.1.1/3028 - Release Date: 07/25/10 20:36:00



  • 9.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-27-2010 10:00
    The cac:Contract in the cac library should provide a more generic
    definition for the nomination period.
    
    Also the definition of the NominationPeriod is not complete as it is just
    explaining the begin of the period and not the end (I believe is the
    transport completation)
    
    Anyway I start thinking there is an overlapping between the ValidityPeriod
    and the NominationPeriod.
    
    So by interpreting the definition provided:
    "The nomination period is the period in which the transport user has to
    book the transport service before the transport should begin."
    
    In other words:
    If the transport user do not book the transport service within the period
    the contract is not valid ?
    
    This seems to be exactly a validity period.
    
    While the nomination period concept is more generally associated to
    nomination of candidates (e.g. assignment of a contract or sub-contract)
    Into this case the period would be different from a validity.
    
    At the end I believe that nomination period is not the right naming for
    the actual intentions and meaning (validity seems to be more appropriate)
    
    I hope I have been clear enough with my English... :)
    
    Cheers,
    
    Roberto
    
    
    > Hi Ken,
    >
    > according to the last decision of TSC, I implemented the option (A).
    >
    > So, to summarize now we have:
    >
    > Consignment. Transport_ Contract. Contract
    >
    > where "Contract" class is as follows:
    >     1 ID
    >     2 IssueDate
    >     3 IssueTime
    >     4 ContractTypeCode
    >     5 ContractType
    >   *6 Note
    >     7 ValidityPeriod
    >     8 ContractDocumentReference
    > * 9 NominationPeriod
    > *10 ContractualDelivery
    >
    > (*added in UBL 2.1)
    >
    > The definitions related to ASBIE 9 and 10 are:
    >
    > NominationPeriod: An association to Period. The nomination period is the
    > period in which the transport user has to book the transport service
    > before the transport should begin.
    >
    > ContractualDelivery: An association to Delivery.
    >
    > I am asking if these definitions should be modified in order to specify
    > that these ASBIEs should be used only in transport context.
    >
    > Best regards
    >
    > Arianna
    >
    >
    > Il 23/07/2010 15:55, Jon Bosak ha scritto:
    >> Hello Arianna,
    >>
    >> I'm leaning toward solution A also, but with no real understanding
    >> of why the new items were felt to be necessary.
    >>
    >> As decided in this week's Atlantic TC call, however, the decision
    >> will be made by the UBL Transport Subcommittee (TSC).  We are
    >> expecting that decision at next week's meeting.
    >>
    >> Jon
    >>
    >> Arianna Brutti wrote:
    >>> Hi Ken,
    >>>
    >>> I analized your proposals and my opinion is as follows: I don't like
    >>> solutions B and D, because of the problems that you described.
    >>>
    >>>  From my point of view A solution is the best, so I agree with
    >>> Roberto, but I think also that the C solution could be acceptable.
    >>>
    >>> I am going to wait for your final decision before to act.
    >>>
    >>> Best regards
    >>>
    >>> Arianna
    >>>
    >>>
    >>>
    >>> il Thu, 22 Jul 2010 16:40:46 +0200 (CEST)
    >>>  "Roberto Cisternino" 


  • 10.  Alternative: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-27-2010 10:47
    Hello,
    
    as an additional alternative I would suggest to use some additional CCTS
    annotations while keeping a generic meaning for the Contract.
    
    1)
    
    
    2)
    
    
    Hope this helps.
    
    Roberto
    
    > The cac:Contract in the cac library should provide a more generic
    > definition for the nomination period.
    >
    > Also the definition of the NominationPeriod is not complete as it is just
    > explaining the begin of the period and not the end (I believe is the
    > transport completation)
    >
    > Anyway I start thinking there is an overlapping between the ValidityPeriod
    > and the NominationPeriod.
    >
    > So by interpreting the definition provided:
    > "The nomination period is the period in which the transport user has to
    > book the transport service before the transport should begin."
    >
    > In other words:
    > If the transport user do not book the transport service within the period
    > the contract is not valid ?
    >
    > This seems to be exactly a validity period.
    >
    > While the nomination period concept is more generally associated to
    > nomination of candidates (e.g. assignment of a contract or sub-contract)
    > Into this case the period would be different from a validity.
    >
    > At the end I believe that nomination period is not the right naming for
    > the actual intentions and meaning (validity seems to be more appropriate)
    >
    > I hope I have been clear enough with my English... :)
    >
    > Cheers,
    >
    > Roberto
    >
    >
    >> Hi Ken,
    >>
    >> according to the last decision of TSC, I implemented the option (A).
    >>
    >> So, to summarize now we have:
    >>
    >> Consignment. Transport_ Contract. Contract
    >>
    >> where "Contract" class is as follows:
    >>     1 ID
    >>     2 IssueDate
    >>     3 IssueTime
    >>     4 ContractTypeCode
    >>     5 ContractType
    >>   *6 Note
    >>     7 ValidityPeriod
    >>     8 ContractDocumentReference
    >> * 9 NominationPeriod
    >> *10 ContractualDelivery
    >>
    >> (*added in UBL 2.1)
    >>
    >> The definitions related to ASBIE 9 and 10 are:
    >>
    >> NominationPeriod: An association to Period. The nomination period is the
    >> period in which the transport user has to book the transport service
    >> before the transport should begin.
    >>
    >> ContractualDelivery: An association to Delivery.
    >>
    >> I am asking if these definitions should be modified in order to specify
    >> that these ASBIEs should be used only in transport context.
    >>
    >> Best regards
    >>
    >> Arianna
    >>
    >>
    >> Il 23/07/2010 15:55, Jon Bosak
    begin_of_the_skype_highlighting     end_of_the_skype_highlighting ha
    scritto:
    >>> Hello Arianna,
    >>>
    >>> I'm leaning toward solution A also, but with no real understanding
    >>> of why the new items were felt to be necessary.
    >>>
    >>> As decided in this week's Atlantic TC call, however, the decision
    >>> will be made by the UBL Transport Subcommittee (TSC).  We are
    >>> expecting that decision at next week's meeting.
    >>>
    >>> Jon
    >>>
    >>> Arianna Brutti wrote:
    >>>> Hi Ken,
    >>>>
    >>>> I analized your proposals and my opinion is as follows: I don't like
    >>>> solutions B and D, because of the problems that you described.
    >>>>
    >>>>  From my point of view A solution is the best, so I agree with
    >>>> Roberto, but I think also that the C solution could be acceptable.
    >>>>
    >>>> I am going to wait for your final decision before to act.
    >>>>
    >>>> Best regards
    >>>>
    >>>> Arianna
    >>>>
    >>>>
    >>>>
    >>>> il Thu, 22 Jul 2010 16:40:46 +0200 (CEST)
    >>>>  "Roberto Cisternino" 


  • 11.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-27-2010 12:13
      |   view attached

    Attachment(s)

    vcf
    tim_mcgrath.vcf   287 B 1 version


  • 12.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-24-2010 06:45
      |   view attached

    Attachment(s)

    vcf
    tim_mcgrath.vcf   275 B 1 version


  • 13.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-24-2010 13:19
    Yes this is another chance but I still think into this case we could just
    append the nominationPeriod and contractualDelivery information to the
    actual Contract's children.
    
    This way contract elements order is preserved and the Contract is still
    generic and suitable for different use cases.
    
    Cheers,
    
    Roberto
    
    > Sorry to have missed out on this thread but i do have another option...
    >
    > D) Dont extend the Contract at all and add the new children to
    > Consignment, as in...
    >   
    >
    > That is ... we dont need a NewTransportThingy - just qualify the
    > additional ASBIEs further.  This is not ideal (the way we had it was
    > logically correct) but as Ken points out we cannot do that.  Option D)
    > is the next best thing.
    >
    >
    > G. Ken Holman wrote:
    >> Hi folks,
    >>
    >> It turns out our decision to accept new dictionary entry names for old
    >> constructs was hiding a backwards compatibility problem.  Thankfully
    >> the sample instances revealed the need to update the model checking.
    >> And thankfully that updated model checking found only the one problem
    >> revealed by the sample instances and not any other problems of the
    >> same ilk.
    >>
    >> Far below is the latest complete report and excerpted here below is
    >> the new addition:
    >>
    >> ASBIEs found in error: 1
    >> Old Parent DEN: "Consignment. Details"
    >> New Parent DEN: "Consignment. Details"
    >> Old name: "TransportContract"
    >> New name: "TransportContract"
    >> Old DEN: "Consignment. Transport_ Contract. Contract"
    >> New DEN: "Consignment. Transport Contract"
    >> Old associated class: "Contract"
    >> New associated class: "Transport Contract"
    >>   Old order:
    >>    1 ID
    >>   *2 IssueDate
    >>   *3 IssueTime
    >>   *4 ContractTypeCode
    >>   *5 ContractType
    >>   *6 ValidityPeriod
    >>   *7 ContractDocumentReference
    >>
    >>   New order (not including newly-introduced optional constructs):
    >>
    >>   New order (all constructs):
    >>    1 Contract
    >>   *2 NominationPeriod
    >>   *3 ContractualDelivery
    >>
    >>
    >> What this means is that until this is fixed UBL 2.1 is not backward
    >> compatible to UBL 2.0 because UBL 2.0 is expecting:
    >>
    >>   


  • 14.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-25-2010 03:02
      |   view attached

    Attachment(s)

    vcf
    tim_mcgrath.vcf   275 B 1 version


  • 15.  RE: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-25-2010 12:34
    Another alternative may be to ask Freightwise to use some other name for
    transport contract that is even more specific to freight.....
    
    


  • 16.  Re: [ubl] Newly detected backward compatibility error - TransportContract

    Posted 07-26-2010 09:53
    No these additional information are also used in construction.
    
    Contractual delivery for instance is referred to the end of works.
    
    Nomination is generally applicable to any contract and sub-contract.
    
    Hope this helps
    
    
    > but aren't nominationPeriod and contractualDelivery quite specific to a
    > contract when used for a consignment - i.e. their context is for
    > transport?
    >
    > we should not overload Contract with context-specific properties (that
    > is why we prefer to use extensions -it is just we cannot in this case)
    >
    >
    >
    > Roberto Cisternino wrote:
    >> Yes this is another chance but I still think into this case we could
    >> just
    >> append the nominationPeriod and contractualDelivery information to the
    >> actual Contract's children.
    >>
    >> This way contract elements order is preserved and the Contract is still
    >> generic and suitable for different use cases.
    >>
    >> Cheers,
    >>
    >> Roberto
    >>
    >>
    >>> Sorry to have missed out on this thread but i do have another option...
    >>>
    >>> D) Dont extend the Contract at all and add the new children to
    >>> Consignment, as in...
    >>>   
    >>>
    >>> That is ... we dont need a NewTransportThingy - just qualify the
    >>> additional ASBIEs further.  This is not ideal (the way we had it was
    >>> logically correct) but as Ken points out we cannot do that.  Option D)
    >>> is the next best thing.
    >>>
    >>>
    >>> G. Ken Holman wrote:
    >>>
    >>>> Hi folks,
    >>>>
    >>>> It turns out our decision to accept new dictionary entry names for old
    >>>> constructs was hiding a backwards compatibility problem.  Thankfully
    >>>> the sample instances revealed the need to update the model checking.
    >>>> And thankfully that updated model checking found only the one problem
    >>>> revealed by the sample instances and not any other problems of the
    >>>> same ilk.
    >>>>
    >>>> Far below is the latest complete report and excerpted here below is
    >>>> the new addition:
    >>>>
    >>>> ASBIEs found in error: 1
    >>>> Old Parent DEN: "Consignment. Details"
    >>>> New Parent DEN: "Consignment. Details"
    >>>> Old name: "TransportContract"
    >>>> New name: "TransportContract"
    >>>> Old DEN: "Consignment. Transport_ Contract. Contract"
    >>>> New DEN: "Consignment. Transport Contract"
    >>>> Old associated class: "Contract"
    >>>> New associated class: "Transport Contract"
    >>>>   Old order:
    >>>>    1 ID
    >>>>   *2 IssueDate
    >>>>   *3 IssueTime
    >>>>   *4 ContractTypeCode
    >>>>   *5 ContractType
    >>>>   *6 ValidityPeriod
    >>>>   *7 ContractDocumentReference
    >>>>
    >>>>   New order (not including newly-introduced optional constructs):
    >>>>
    >>>>   New order (all constructs):
    >>>>    1 Contract
    >>>>   *2 NominationPeriod
    >>>>   *3 ContractualDelivery
    >>>>
    >>>>
    >>>> What this means is that until this is fixed UBL 2.1 is not backward
    >>>> compatible to UBL 2.0 because UBL 2.0 is expecting:
    >>>>
    >>>>