AW: [ubl] [ver] a prototype that works

["David Kruppke" <kruppke@gefeg.com>]

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
>
>