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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

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