[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] [ver] a prototype that works
David, Could you please define what you mean by redeclare? Mark > -----Original Message----- > From: David Kruppke [mailto:kruppke@gefeg.com] > Sent: Tuesday, April 19, 2005 4:09 AM > To: ubl@lists.oasis-open.org > 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_workgr oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]