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


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


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