OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: [ubl] [ver] a prototype that works


Apologies - I just realised that I should forward
this (I received it a few hours ago).
 
Steve
----- Original Message -----
From: A. G.
Sent: Tuesday, April 19, 2005 10:58 AM
Subject: Re: [ubl] [ver] a prototype that works

Stephen:
 
Here's my mini-sample. I haven't had a chance to do the write-up yet, but will try to get done later today.
 
Cheers,
 
Arofan

Stephen Green <stephen_green@seventhproject.co.uk> wrote:
Firstly apologies to David that I didn't see your comment
here until after the TC Pacific call. I reported that you'd been
OK about the discussed approach so it got minuted but I hadn't
seen your latest comment. Sorry David.

I do sympathise with the concerns about what happens when we get
multiple minor versions.

In the meantime my own view is that we should not preclude
the polymorphic design in the next version and that it should
therefore be a major version to fix the need to have every
element globally declared and not have an exception for IDs
and Codes.

I attach my prototype sets of Schemas here which seem to
demonstrate how the polymorphism can be achieved with
an appropriate major version (which I've called 2.0 for
illustration) as described above and an initial minor version
with the substitutionGroups (for Invoice, InvoiceLine and Item
in each case extending with a new BBIE called InspectionDate,
again for illustration and which I've called 2.1).

[Please note I am sending this as a zipped file with the extension
changed to .zzz to help with certain firewalls. It might be that
this ends up as a linked file on the email archives with a .bin
extension which you may need to 'Save As' with a .zip
extension before being able to open it with a zip tool.]

At the [ver] meeting yesterday Arofan announced that he hopes
to send out today documentation of the polymorphic design
proposal (which we think may differ from my prototype - there
are multiple ways to do this it seems so we'd need not just a
decision about whether to continue with it but also on the
more exact details of it if we do continue with it), including
example fragments. Maybe there is a way to minimise the
negative impact of the complexities with multiple minor
versions about which David has voiced concerns (as we each
did in SSC).

It might be a good further exercise to produce a further prototype
when Arofan's design is seen and then perhaps to produce a
prototype of a 2.2 minor version to see how there might be problems
and how they might be managed.

All the best

Stephen Green



----- Original Message -----
From: "David Kruppke"
To:
Sent: Tuesday, April 19, 2005 9:09 AM
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_workgroups.php
>

UBLTest.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]