David,
Could you please define what you mean by redeclare?
Mark
> -----Original Message-----
> From: David Kruppke [mailto:]
> Sent: Tuesday, April 19, 2005 4:09 AM
> To:
> 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:]
> > Gesendet: Montag, 18. April 2005 16:46
> > An:
> > Cc:
> > 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:
> > Cc:
> > 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
>
>
