[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]