[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] urgent ndr rules question/clarification
Anne: Anne: Since I stopped being an active participant and a lurker, I do not generally comment, but this is an incredibly serious issue that you raise. If you change this versioning scheme, you will absolutely invalidate a lot of the underlying thinking within NDR concerning the use of namespaces, modularity, and many other details, such as the naming conventions. These issues were debated long and hard within NDR while I was still active in the group, and abandoning them has some pretty drastic consequences: - You completely invalidate the approach to extension/customization, and the work done in that area, as it relies on the schema exhibiting the inheritance in a processable fashion across versions. - You run the risk of producing non-backward-compatible changes in minor versions, which are, under the current scheme, disallowed by the extension and derivation features of XML schema. - You render pointless many of the decisions about modularity and packaging, which assumed the current NDR kind of extension/derivation mechanism being in place. The impact of this would be a *lot* of re-work of the existing NDR, at a minimum a lot of analysis. - You invalidate the naming rules in NDR, vis-à-vis ebXML Core Components spec (names across versions, even if having different, modified content, must be dis-ambiguated by their namespaces, while maintaining their identity and their names, as derived from the corresponding BIE. NDR uses the extension/derivation features of schema to reflect this). Changes to the spreadsheets cannot be so (incredibly) huge: all you need to know is if a specific construct is being inherited from a minor version, or is new to the current one. (Ideally, the spreadsheets for each version would contain only new information, but I gather that is not how they've been constructed.) Add a column to the spreadsheet which identifies the version of each construct, identify the differences, and output them. Since the names of types and elements must be the same across minor versions - disambiguated only by their namespaces - then the names of the types and elements are predictable. I'm sure this is not a simple task, and I don't mean to trivialize it, but it is worth the effort it will take. Otherwise, NDR will simply have stopped making sense, as we will have compromised the integrity of the design in very serious (IMHO fatal) ways. Cheers, Arofan Gregory -----Original Message----- From: Anne.Hendry@Sun.COM [mailto:Anne.Hendry@Sun.COM] Sent: Thursday, February 24, 2005 11:43 AM To: ubl@lists.oasis-open.org Subject: [ubl] urgent ndr rules question/clarification 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]