[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Newly detected backward compatibility error - TransportContract
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: > <cbc:Location> and <cac:Location> are different > XML names on which to base processing. > > This (D) proposal is introducing a new kind of > UBL name conflict with two ASBIEs named > "Transport Contract" that just point to different > structures. The uniqueness in the model is > preserved by the unique DENs, but the uniqueness > happens not to be coincidentally reflected in the > namespace-qualified UBL names. The DEN is not > exposed in an XML instance, while the > namespace-qualified UBL name is exposed in an XML > instance. Both elements are named > <cac:TransportContract> on which to base processing. > > The "pro" of (D) is this is certainly the > *simplest* change for Arianna: restore the DEN > in <cac:TransportContract> in Consignment to what > it was in UBL 2.0, and we are done. > > The "con" of (D) is this now means > <cac:TransportContract> has two different > definitions based on its parent, that is its > context. This is the first time UBL programmers > who may be basing their logic on the > namespace-qualified UBL name will have to add > extra coding in order to now determine the > context in which the UBL construct is found. > > In my own work with XML I have no problem > accommodating an element's parent. However, I > have noticed in some of my students a naïveté in > that they base all of their processing on an > element's name and not on the element's > context. This naïveté may extend to the > application programming interfaces that > programmers use based on the experience of the > developers of the API, but that is just supposition on my part. > > So I've described (D) here in case anyone is > thinking about it as an option. I am not > convinced it is better than (A) (preserved below) > because of the possibility of future push-back > from naïve XML programmers or incomplete software. > > . . . . . . . . . . . . Ken > > At 2010-07-18 22:02 -0400, I 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 > > -- * 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]