[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: SV: [ubl-psc] UBL PSC TC- Schema Generation
I have some empathy with Ken's view but we have to be guided by the policy on UBL 1.0 -> 2.0 The first princple was that any changes to an ASBIE or BBIE (including cardinality) meant a new version. So we cannot track to evolution of any BIE. Remember we are a semantic library and so changes to properties mean changes to semantics (such as a changed business rule). Just existing or not existing is too coarse a distinction. Secondly, if any ASBIE or BBIE in an ABIE changes or is added (ie become a new version) then the ABIE becomes a new version too. However we did not permit the ripple effect. If we look at Branch it stayed at 1.0 even though it associated to Address which become 2.0 (because of several new BBIEs). The argument for this is that the structure of Branch remained the same, it still associated to Address - even if that was not the same Address. The ABIE Address changed, but the ASBIE from Branch to Address did not. The version of the ASBIE remained at 1.0 and therefore the ABIE Branch did not change. It is good that we revisit this, but I suggest we stick with past practice. G. Ken Holman wrote: > At 2009-10-09 22:39 +0200, Peter L. Borresen wrote: >> I see your point. Because of the ripple effect if a ABIE has a >> version 2.1 >> BBIE, then itself becomes a 2.1 ABIE. An ABIE cannot contain ASBIEs >> or BBIEs >> of a higher version. Tim, please correct me if I am wrong. > > I know you are not asking me, Peter, you are asking Tim ... but I'm > more confident now after explaining in my post > http://lists.oasis-open.org/archives/ubl-psc/200910/msg00011.html and > thinking about it after that the column should be reserved for the > version number that a row in the model was added to the model, not > when its children were last changed. > > One can derive the latest version by when its contents were last > changed by looking at the versions of its children. But one loses the > version an ASBIE was added if it is overwritten with that information > that can be derived simply from its members. > > Why lose useful information by information that can be calculated when > needed? > > If I'm looking at the model for UBL 2.7, I would think it would be > very useful to know when a particular ABIE was introduced into UBL (in > case I have to roll back to it for some reason). It would tell me, > for example, that I cannot roll back to before version 2.4 because up > to 2.3 the particular ABIE was not in the model. > > Though I wonder if I could look at the earliest version of any of an > ABIEs children to know when that ABIE was created ... but that > introduces a different meaning for the column for ABIEs than for > ASBIEs and BBIEs. In order to keep the meaning of the column the same > for all rows, I think we have to interpret the column as the version > in which the row was introduced into the model. > > So I believe that indeed an ABIE can contain ASBIEs and BBIEs of a > higher version. > > I hope this is helpful ... and I am curious what Tim thinks as well. > > . . . . . . . . . . . Ken > > > -- > Upcoming: hands-on code list, UBL, XSLT, XQuery and XSL-FO classes > in Copenhagen Denmark and Washington DC USA, October/November 2009 > Interested in other classes? http://www.CraneSoftwrights.com/o/i/ > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video > Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 > Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 > 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 >
begin:vcard fn:Tim McGrath n:McGrath;Tim org:Document Engineering Services Ltd. email;internet:tim.mcgrath@documentengineeringservices.com title:Managing Director tel;work:+45 36 95 33 58 tel;cell:+61 438 352228 url:www.documentengineeringservices.com version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]