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

[<MCRAWFORD@lmi.org>]

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