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


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
.





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