RE: [ubl] urgent ndr rules question/clarification

[<MCRAWFORD@lmi.org>]

Anne,

I Completely agree with Arofan and Eduardo.  If the gefeg software can't
handle the versioning scheme, then we toss the software - not the
versioning scheme.

Mark
 

> -----Original Message-----
> From: Eduardo Gutentag [mailto:Eduardo.Gutentag@Sun.COM] 
> Sent: Thursday, February 24, 2005 4:36 PM
> To: Anne.Hendry@Sun.COM
> Cc: ubl@lists.oasis-open.org
> Subject: Re: [ubl] urgent ndr rules question/clarification
> 
> Arofan and I just had a short email conversation in which we 
> agreed that if this were to happen, then it would be the 
> death of UBL inasmuch as customization as conceived until now 
> is concerned. There was an understanding that 1.1 (and 1.2, 
> etc, if any) would be derived from 1.0 on the basis of the 
> customization guidelines and the current NDR rules. If that's 
> not to be because some automation software cannot implement 
> something, fine, but please remove the customization 
> guidelines from the package.
> 
> Ah, I see that Arofan has posted something on the subject, so 
> I'll shut up now. I couldn't agree more with him (at least on 
> this, I still have an issue with his fishing ;) )
> 
> On 02/24/2005 10:42 AM, Anne.Hendry@Sun.COM wrote:
> > Regarding rules
> > 
> > [VER 8] a ubl minor version doc schema must import its 
> immediately preceding version document schema.
> > [VER 9] ... new ... existing ... limited to the use the use 
> of xsd:derivation and xsd:restriction ...
> > 
> > The implication of these rules may be quite drastic in 
> terms of being 
> > able to generate schemas programmatically and are not sure 
> if we can 
> > do this with the spreadsheets we have as we'd need to 
> either include 
> > the old ss into the new ss by adding new columns or import 
> both ss into ef.
> > 
> > For 1.0, since the ss and schemas were not aligned, then 
> there would 
> > need to be a regeneration of 1.0 model within ef from the 
> 1.0 schemas, 
> > and any incompatability there woudl cause a problem.  Or, could 
> > generate a schema that imports the old one and then 
> generate a ss and try to do a diff.
> > 
> > Do we really want these rules?  It's one possible approach 
> to schema 
> > versioning, and if doing schemas by hand may work, but 
> doesn't fit an 
> > automatic generation process such as the one we are persuing.  You 
> > also would need a whole host of additional ndr rules.  For example, 
> > how does this rule take into account both tc and oasis 
> versions?  Need further ndr rules to allow these rules to be kept.
> > 
> > In addition, in [VER 9] what does 'exisiting' or 'new' mean here 
> > except that it is by comparision with the version mentioned 
> in [VER 8]?  The words 'alter'
> > and 'new' require you to have two versions available of 
> both model and scheams.
> > Reading behind this, it seems this is an implementation of 
> > customization, and is a nice idea, and has value, but the amount of 
> > work from both ssc and ndr to implement these rules cannot 
> be done in the timeframe we have.
> > 
> > A better way to achieve similar results maybe be to build a 
> test db of 
> > valid examples to test back compatibility.  If the desire is to 
> > demonstrate customization methodology with these rules then 
> we have a larger problem for 1.1.
> > 
> > 
> > - SSC
> > 
> > 
> > 
> > To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave
> _workgroup.php.
> > 
> 
> -- 
> Eduardo Gutentag               |         e-mail: 
> eduardo.gutentag@Sun.COM
> Corporate Standards            |         Phone:  +1 510 550 
> 4616 (internal x31442)
> Sun Microsystems Inc.          |         W3C AC Rep / W3C AB 
> / OASIS BoD
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave
> _workgroup.php.
> 
>