[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]