I admit to thinking 'anything but substitution
groups' but we'd
better discuss it today.
The codelist discussion of the same mechanism on
ubl-dev
(e.g. http://lists.oasis-open.org/archives/ubl-dev/200502/msg00012.html )
never really got
resolved.
Of course the UBL NDR outlaws the
mechanism.
Do sg's actually offer anything we can't
get
from having two sets of Schemas?
What is the difference between a set of Schemas
that validates
two versions because it links to a second set of
previous schemas
by import and merely having two sets of Schemas to
do the same job?
What is involved in trying to avoid not just
changes to the
namespaces between versions but changes to the
'schemaLocation' values too?
My main question is how does the party validating
the instance
know whether an unknown extension element has been added
to a type and whether the extra element
is invalid or just part
of a version they didn't know about? I.e. doesn't
this design
prevent any element added according to extension
compatibility
rules ever being invalid.
Does the mechanism cause more confusion than it
solves?
Is it supported as fully in tools as would be
warranted for a
horizontal standard such as UBL is designed to
be?
...
Here's my tuppence worth.
All the best
Steve
----- Original Message -----
From:
Stephen Green
To:
Sent: Tuesday, April 12, 2005 3:28
PM
Subject: [ubl] [ver] (AW/Fwd) to consider
before call
----- Original Message -----
From: A. G.
To: Stephen Green
Sent: Tuesday, April 12, 2005 1:47 PM
Subject: Re: [ver] Anything to consider before call?
Stephen:
Many thanks.
Yes, I think I actually figured out a solution, although i haven't had
time to really work up the samples yet.
Substitution groups.
I was looking at your samples, and I realized that the one thing we do
differently in the SDMX implementation of this aspect of NDR (we don't use all
the rules, as they don't always apply) is that we have each extendable type
represented as the head of a substitution group.
Thus:
In NS A v. 1.0, I declare Item and Line. Each type is the head of a
substitution group.
In NS B v 1.0, I declare the Invoice, as per your example from our
earlier call.
If I go to create v. 1.1 of these namespaces, I can extend the Item
in NS A v. 1.1, and also extend the Line (which contains the Item). If I
indicate that the Item is a member of the Item substitution group, however,
then I get the extended version of Item instead of the old one when I create
the new Line (which, of course, I use in the new Invoice, which can also be
extended).
Had you considered this approach? It has some ramifications, but avoiding
the problem you ran into is exactly why substitution groups were
invented. I know this was discussed in NDR soime time ago, but it clearly
didn't make it into the spec.
I thionk we should discuss this on the call, unless jet-lag is making me
miss some obvious flaw.
Cheers,
Arofan
Stephen Green
<> wrote:
Arofan
I just realised you can't post to the ubl
list.
If you've anything you'd like be posted to the
list
before the meeting today, feel free to post
it
to me and I'll forward it on. However I'll be
away
from email for 1 hour prior to the
call.
Unfortunately I'll be out of email range
Thurs
and Friday but we can sort something out
before
then. (The modeling team have had to send
me
to a meeting in Europe so I'll only have
limited
contact Thursday and Friday I'm
afraid.)
All the best
Steve
