[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] [ver] a prototype that works
Firstly apologies to David that I didn't see your comment here until after the TC Pacific call. I reported that you'd been OK about the discussed approach so it got minuted but I hadn't seen your latest comment. Sorry David. I do sympathise with the concerns about what happens when we get multiple minor versions. In the meantime my own view is that we should not preclude the polymorphic design in the next version and that it should therefore be a major version to fix the need to have every element globally declared and not have an exception for IDs and Codes. I attach my prototype sets of Schemas here which seem to demonstrate how the polymorphism can be achieved with an appropriate major version (which I've called 2.0 for illustration) as described above and an initial minor version with the substitutionGroups (for Invoice, InvoiceLine and Item in each case extending with a new BBIE called InspectionDate, again for illustration and which I've called 2.1). [Please note I am sending this as a zipped file with the extension changed to .zzz to help with certain firewalls. It might be that this ends up as a linked file on the email archives with a .bin extension which you may need to 'Save As' with a .zip extension before being able to open it with a zip tool.] At the [ver] meeting yesterday Arofan announced that he hopes to send out today documentation of the polymorphic design proposal (which we think may differ from my prototype - there are multiple ways to do this it seems so we'd need not just a decision about whether to continue with it but also on the more exact details of it if we do continue with it), including example fragments. Maybe there is a way to minimise the negative impact of the complexities with multiple minor versions about which David has voiced concerns (as we each did in SSC). It might be a good further exercise to produce a further prototype when Arofan's design is seen and then perhaps to produce a prototype of a 2.2 minor version to see how there might be problems and how they might be managed. All the best Stephen Green ----- Original Message ----- From: "David Kruppke" <kruppke@gefeg.com> To: <ubl@lists.oasis-open.org> Sent: Tuesday, April 19, 2005 9:09 AM Subject: AW: [ubl] [ver] a prototype that works > I'm sorry, I cannot make the call today evening (it's my birthday ;-) ). > > My opinion is the following: > > We should consider to redeclare all structures in UBL 1.1 rather then using > a substitutionGroup or/and extension/restriction mechanism. > > Using redeclaration we would have ease-to-use schemas that users can > understand. > > > Using substituionGroups/extension/restriction lead to very complicated > schemas. Suppose there would be a UBL 1.5 version, then a user has to handle > 6 namespaces at the same time i.e for the commonAggregateComponents (UBL > 1.0, 1.1, 1.2, 1.3, 1.4 and 1.5). I think this would prevent users from > implementing UBL. > > > Best Regards, > > > David > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: Stephen Green [mailto:stephen_green@seventhproject.co.uk] > > Gesendet: Montag, 18. April 2005 16:46 > > An: ubl@lists.oasis-open.org > > Cc: ilg21@yahoo.com > > Betreff: Re: [ubl] [ver] a prototype that works > > > > > > I'm just working through the NDR changes which might be required > > to support > > this > > design (below). > > > > > > Note, the TC/NDR Team agreed that the [ver] team *needn't* agree > > to propose > > such NDR changes but that we could > > propose such things if we wished. > > > > So here are my thoughts on the matter. > > > > > > > > #1. The following rules would need changing, I think: > > > > ELD2: All element declarations MUST be global with the exception of ID and > > Code > > which MUST be local. > > > > to > > > > ELD2: All element declarations MUST be global. > > > > > > #2. Current discussions in the NDR team may require that the > > verioning rules > > change > > (section 3.5, VER1ff) to allow the same namespace to be used for minor > > versions > > as for major versions but this hasn't been resolved yet. > > > > #3. A new prefix for the added BBIEs would require, I think, an > > amended rule > > NMS10: The UBL:CommonBasicComponents schema module MUST be represented > > by the token "cbc" for major and previous minor version BBIEs and token > > "cbc..." > > (to be decided) for additional BBIEs added by extension to a current minor > > version. > > > > #4. Depending on whether *all* types are derived, even if unchanged, there > > may be the need > > for a new prefix for types which are extended and so this may > > need a change > > to rule > > NMS8 similar to that for NMS10. > > > > #5. New UDT's, if the design requires that they be used > > *alongside* previous > > version UDTs > > may require an amendment to rule NMS14 to allow for a second, modified udt > > prefix. > > > > #6. New SDT's, if the design requires that they be used > > *alongside* previous > > version SDTs > > may require an amendment to rule NMS16 to allow for a second, modified sdt > > prefix. > > > > (#7. GXS2 may provide a precendent for the proposal to combine UBL's and > > ATG2's > > different NDR designs in any future joining of our efforts since > > though the > > main objection to > > dual Schemas - UBL design and ATG2 design - for the same instances might > > be the added complexity, we have already done this a bit with > > our xsd/xsdrt > > dual normative Schemas and had little negative feedback. Plus the CEFACT > > folk > > already considered this at a recent meeting and found few if any issues > > with it > > from their point of view.) > > > > #8. Section 4.2 Type Naming Rules may require a new rule along > > the lines of > > rule CTN1 > > "A UBL xsd:complexType name based on an ccts:Aggregate > > BusinessInformationEntity MUST be the ccts:Dictionary > > EntryName with the separators removed and with the "Details" suffix > > replaced with "Type"." to say perhaps that if xsd:derivation requires the > > addition of an intermediate > > type from which another type can be derived, the name of the type "...MUST > > be the ccts:Dictionary > > EntryName with the separators removed and with the "Details" suffix > > replaced with "BaseType"." (CTN6 or CTN1b) > > > > #9 Rule GXS5 currently states: The xsd:substitutionGroup feature > > MUST NOT be > > used. > > This would need to be changed e.g. to > > The xsd:substitutionGroup feature MUST NOT be used other than to allow > > derivation of elements from previous version > > elements and then only with the previous element as the header element. > > Abstract headers MUST NOT > > be used with an xsd:substitutionGroup. > > > > #10. The rule GXS1 may be amended to include the imports and extra > > namespaces in a minor version and the > > ordering of intermediate ...BaseType types and the derived types (keeping > > these together as recommended in the > > Customisation Methododlogy Paper). > > > > #11. The rule GXS13 "Complex Type extension or restriction MAY be > > used where > > appropriate" might be > > extended to say "... using a xsd:substitutionGroup with the > > original element > > to allow multiple derivations > > within the same component model" > > > > > > > > That's all the changes that stand out to me. There may of course > > be others. > > > > This would form a slightly non-backwards compatible NDR even for > > the initial > > (amended) major version > > due to the change to rule ELD2 (#1. above). Perhaps it would be a possible > > NDR 2.0 preparing the way > > for a UBL 2.0 and polymorphic 2.1,... 2.n > > > > Food for thought/discussion. > > > > All the best > > > > Steve > > > > > > > > > > ----- Original Message ----- > > From: Stephen Green > > To: ubl@lists.oasis-open.org > > Cc: ilg21@yahoo.com > > Sent: Monday, April 18, 2005 2:35 PM > > Subject: [ubl] [ver] a prototype that works > > > > > > Folks > > > > Greetings. I've a problem sending it today > > (CD not reading properly while away from home) > > but I've written a full, working (aparently) prototype > > using the substitutionGroups with the previous release > > types as headers. I made IDs and Codes, in a prototype > > 2.0 (major) version, all global then created a prototype minor > > version which extended Item, InvoiceLine and Invoice > > apparently successfully (with the added InspectionDate). > > > > A consideration is - this required new prefixes for changed cac's > > as well as for new cbc's. By extending (not necessarily with > > actual added bie's) *every* type it might be that just the extra > > prefixes for the new bbie's are required (e.g. cbc1-1:InspectionDate) > > whereas all extended types might still have the one prefix > > cac: (or in: for an Invoice document, say) but of course with > > the new namespace. This would be more time-consuming to > > prototype of course. > > > > So the above at least needs considering. > > > > I'll be waiting for anyone who wants to attend today but > > otherwise I'll 'see' folk tomorrow. By then I might have been > > able to send the prototype but I expect you get the idea anyway. > > > > This looks promising - many thanks to Arofan for guiding > > us to this. > > > > All the best > > > > Steve > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your > > TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
xsd-derivation-prototype-ver-sdg-1.zzz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]