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: Re: [ubl] [ver] (AW/Fwd) to consider before call

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
----- Original Message -----
Sent: Tuesday, April 12, 2005 3:28 PM
Subject: [ubl] [ver] (AW/Fwd) to consider before call

----- Original Message -----
From: A. G.
Sent: Tuesday, April 12, 2005 1:47 PM
Subject: Re: [ver] Anything to consider before call?

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

Stephen Green <stephen_green@seventhproject.co.uk> wrote:
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

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