OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Newly detected backward compatibility error - TransportContract


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...
>>>   <cac:Consignment>
>>>     <cac:TranportContract>
>>>       ID, IssueDate, IssueTime, etc. (per the old order above)
>>>     </cac:TransportContract>
>>>     <cac:TransportContractNominationPeriod>
>>>     </cac:TransportContractNominationPeriod>
>>>     <cac:TransportContractContractualDelivery>
>>>     </cac:TransportContractContractualDelivery>
>>>     </cac:Consignment>
>>>
>>> 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:
>>>>
>>>>   <cac:Consignment>
>>>>     <cac:TransportContract>
>>>>       ID, IssueDate, IssueTime, etc. (per the old order above)
>>>>
>>>> But the way the schemas are now written, a UBL 2.1 instance is
>>>> expecting:
>>>>
>>>>   <cac:Consignment>
>>>>     <cac:TransportContract>
>>>>       Contract, NominationPeriod, ContractualDelivery
>>>>
>>>> So, we need to change something.  Note in the error report the "old
>>>> order" and "new order" are totally different, so that part of the
>>>> error report is nonsensical for this particular situations.  In other
>>>> error situations it might coincidentally be the same order.
>>>>
>>>> <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.
>>>>
>>>> (B) We could add a new ABIE Transport Contract that has all of the
>>>> children of Contract and then the new children as well (this way UBL
>>>> 2.0 is backward compatible to both the new <Contract> and the new
>>>> <TransportContract>).  But in a future version of UBL if we have new
>>>> contract properties we would have to remember to add them in two
>>>> places.
>>>>
>>>> (C) We could add a new ASBIE to <Consignment> which has only the new
>>>> children:
>>>>
>>>>   <cac:Consignment>
>>>>     <cac:TranportContract>
>>>>       ID, IssueDate, IssueTime, etc. (per the old order above)
>>>>     </cac:TransportContract>
>>>>     <cac:NewTransportThingy>
>>>>       <cac:NominationPeriod>
>>>>       </cac:NominationPeriod>
>>>>       <cac:ContractualDelivery>
>>>>       </cac:ContractualDelivery>
>>>>     </cac:NewTransportThingy>
>>>>   </cac:Consignment>
>>>>
>>>> ... so I thought I'd try and propose the name of the new element above
>>>> "NewTransportThingy" by reading the definitions of the two members:
>>>>
>>>> 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.
>>>>
>>>>
>>>> And because of the tautological definition used, I don't know what the
>>>> combination is trying to represent.  So I'll leave it with the TSC to
>>>> decide which of the three ways to go.  I think my vote is (A).
>>>>
>>>> BTW, the prevalence in UBL 2.0 and 2.1 of these tautological
>>>> definitions I think takes a lot away from our specification.  And,
>>>> when I try to teach UBL in the classroom, I get burned by their
>>>> presence in the model when a student asks me a question.  The
>>>> definition above for "ContractualDelivery" tells me nothing at all.  I
>>>> can see it is an association to Delivery because it is associated with
>>>> delivery.  But I cannot (and my students cannot, and our users cannot)
>>>> understand what to put in <ContractualDelivery> without knowing the
>>>> definition the UBL designers had in mind regarding why they had to add
>>>> it to the model.  Using a tautological definition adds nothing and
>>>> doesn't serve the user.  I realize it will be a lot of work, but I
>>>> would like to propose in PRD1 review that *every* tautological
>>>> definition be replaced with a proper semantic definition that conveys
>>>> some real definition information to the reader.
>>>>
>>>> So, over to you TSC ... how do we fix the transport contract
>>>> situation?  One of the above three approaches, or a fourth approach I
>>>> haven't thought of?
>>>>
>>>> Thanks!
>>>>
>>>> . . . . . . . . . .  Ken
>>>>
>>>> Renamed old DENs in new model: 18
>>>> Application Response. Version Identifier. Identifier: Application
>>>> Response. Version. Identifier
>>>> Certificate Of Origin. Version Identifier. Identifier: Certificate Of
>>>> Origin. Version. Identifier
>>>> Consignment. Transport_ Contract. Contract: Consignment. Transport
>>>> Contract
>>>> Item Comparison. Price. Amount: Item Comparison. Price Amount. Amount
>>>> Monetary Total. Allowance Total Amount. Amount: Monetary Total.
>>>> Allowance_ Total Amount. Amount
>>>> Monetary Total. Charge Total Amount. Amount: Monetary Total. Charge_
>>>> Total Amount. Amount
>>>> Order Change. Customer Reference. Text: Order Change. Customer_
>>>> Reference. Text
>>>> Order Change. Sales Order Identifier. Identifier: Order Change. Sales_
>>>> Order Identifier. Identifier
>>>> Order Change. Sequence_ Number. Identifier: Order Change. Sequence
>>>> Number. Identifier
>>>> Order Reference. Sales Order Identifier. Identifier: Order Reference.
>>>> Sales_ Order Identifier. Identifier
>>>> Order Response. Customer Reference. Text: Order Response. Customer_
>>>> Reference. Text
>>>> Order Response. Sales Order Identifier. Identifier: Order Response.
>>>> Sales_ Order Identifier. Identifier
>>>> Order. Customer Reference. Text: Order. Customer_ Reference. Text
>>>> Order. Sales Order Identifier. Identifier: Order. Sales_ Order
>>>> Identifier. Identifier
>>>> Packing List. Version Identifier. Identifier: Packing List. Version.
>>>> Identifier
>>>> Receipt Line. Oversupply Quantity. Quantity: Receipt Line. Oversupply_
>>>> Quantity. Quantity
>>>> Signature. Validator Identifier. Identifier: Signature. Validator.
>>>> Identifier
>>>> Status. Sequence. Identifier: Status. Sequence Identifier. Identifier
>>>>
>>>>
>>>> Bad code type property terms: 0
>>>>
>>>>
>>>> Duplicated class/qualifier/property terms: 0
>>>>
>>>>
>>>> Bad name components: 0
>>>>
>>>>
>>>> Mismatched name components for UBL Name: 3
>>>> "TaxExclusiveAmount": inconsistent naming components (2)
>>>>   Budget Amount. Tax Exclusive_ Amount. Amount
>>>>   Monetary Total. Tax Exclusive Amount. Amount **
>>>> "ValueAmount": inconsistent naming components (3)
>>>>   Capability. Value_ Amount. Amount
>>>>   Goods Item. Value. Amount **
>>>>   Stock Availability Report Line. Value_ Amount. Amount
>>>> "PackSizeNumeric": inconsistent naming components (2)
>>>>   Item. Pack Size. Numeric
>>>>   Utility Item. Pack_ Size Numeric. Text **
>>>>
>>>>
>>>> Orphaned ABIEs not being referenced by an ASBIE: 0
>>>>
>>>>
>>>> Qualified ABIEs:  0
>>>>
>>>>
>>>> Qualified ASBIEs:  0
>>>>
>>>>
>>>> Duplicate UBL Names for the same ABIE type: 0
>>>>
>>>>
>>>> Missing old Data Type Qualifications in new model: 1
>>>> "Status. Condition Code. Code" old="Transportation Status" new=""
>>>>
>>>>
>>>> Missing new Data Type Qualifications in new data types: 0
>>>>
>>>>
>>>> Cardinalities found in error: 0
>>>>
>>>>
>>>> Sequences found in error (by DEN): 0
>>>>
>>>>
>>>> Sequences found in error (by name): 0
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
>>>> Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
>>>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
>>>> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
>>>> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/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
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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


-- 
* 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]