Apologies - I just realised that I should
forward
this (I received it a few hours ago).
Steve
----- Original Message -----
From: A. G.
To: Stephen Green
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 <>
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:]
> > 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_workgroups.php
>
UBLTest.zip
