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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl] urgent ndr rules question/clarification


Hi Sylvia,

My assumption is that it is purely a business decision to be made by
GEFEG.  It clearly is not UBL or anyone else's place to do so.  Please
understand though that the UBL versioning scheme is also the ATG
versioning scheme and the US DON versioning scheme and the ...
Versioning scheme and the ... Versioning scheme .....

Mark
 

> -----Original Message-----
> From: Sylvia Webb [mailto:swebb@gefeg.com] 
> Sent: Friday, February 25, 2005 9:47 AM
> To: CRAWFORD, Mark
> Cc: ubl@lists.oasis-open.org
> Subject: RE: [ubl] urgent ndr rules question/clarification
> 
> Mark,
> 
> The issue isn't that EDIFIX can't handle the versioning 
> scheme.  The issue is whether we should spend time and money 
> on customizing EDIFIX for a few UBL developers versus meeting 
> the requirements of our customers who prefer to use the real 
> modeling features of EDIFIX and not spreadsheets.
> 
> Sylvia
> -----Original Message-----
> From: MCRAWFORD@lmi.org [mailto:MCRAWFORD@lmi.org]
> Sent: Friday, February 25, 2005 4:25 AM
> To: ubl@lists.oasis-open.org
> Subject: RE: [ubl] urgent ndr rules question/clarification
> 
> 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.
> > 
> > 
> 
> 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
> .
> 
> 
> 
> 
> 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.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]