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

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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