Re: [ubl-dev] Re: Code list extensibility and substitutiongroups

["William J. Kammerer" <wkammerer@novannet.com>]

1. I hope that UBL currently offers two types of codelist, as some
"code" lists really aren't finite lists that would lend themselves to
validation with enumerations anyway. For example UPCs or GTINs might be
so voluminous (even for a single supplier presumably doing the
validation) that enumerations would be out of the question. Even a
regular expression validation wouldn't work if the check digit has to be
validated.

2. UBL "can offer codes in a way that allows validation using the XSD
Schemas but only for" those code sets maintained by authoritative
parties where the lists can be easily gotten hold of.

3. I don't see the "need to offer an alternative for folks who wish to
not use the supplied codes." We're talking about "code sets maintained
by authoritative parties," after all. If it's authoritative, say ISO
4217, then you SHOULD use the specified codes (except for Requirement
26's extensibility "desires").

4. That's my understanding - that substitution groups might solve
Requirement 26.

5. This is a whopper but I see your point. Take ISO 4217 currency codes
for example; when you substitute your own code list, the authoritative
ISO 4217 code list has been effectively "disappeared." We have to rely
on "honesty" that folks have merely culled the authoritative list, and
if they have added any new codes at all, they are few and well
considered.

But so what if not? Keep in mind that I'm not even one of the proponents
of code list subsetting and extension. I could live without it. I just
want to be guaranteed that only one of the "authoritative" three
character alpha ISO 4217 codes makes it into my application. I'll then
worry about making sure nobody tries to pass off "CAD" to me in my
application. This is sort of what everyone in Ohio and Michigan has to
do when he receives change: we carefully check all the pennies, nickels,
dimes and quarters to make sure they are real and not those ersatz
Canadian versions.

And if I want to "extend" a list - e.g., invent a new currency code for
just me and my trading partners (say, Chuck E. Cheese tokens, or "CHZ"),
my application can intercept exceptions for a currency code that's not
valid with respect to its type 'CurrencyCodeContentType' - and simply
check the code against an exception list.

William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320

----- Original Message ----- 
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
To: ">" <<ubl-dev@lists.oasis-open.org>
Sent: Tuesday, 22 February, 2005 06:09 AM
Subject: Re: [ubl-dev] Re: Code list extensibility and
substitutiongroups


Folks

Please forgive my writing only as somewhat of a novice in XSD
but I'd appreciate anyone showing me how the following reasoning
might be wrong.

As an aside, wouldn't it be a plausible argument against
substitutionGroups
 that folk like myself, not expert in
XSD but likely to be responsible for implementations nonetheless, would
find substitutionGroups a little perplexing (even if just for failure to
see their value in this
context and therefore reluctance to invest adequate time into adopting
them).
I think my own Government's XSD guidelines are to avoid the more obscure
aspects
of XSD in Schema architecture, perhaps for related reasons.

Anyway, here is my reasoning which makes me reluctant to accept
substitutionGroups in UBL
for codelists (so please convince me of where I'm wrong, as I may well
be wrong):

(Apologies for the length and complexity of this due to lack of time for
editing)



1. we (UBL) currently offer two types of codelist, those with
    codes supplied and those without (the former having
    sub-categories too)

2. we offer codes in a way that allows validation using
    the XSD Schemas but only for some codes

3. if there were the need to offer an alternative for
    folks who wish to not use the supplied codes, it might be
    possible to offer something using xsd:choice so that
    it keeps the possibility of validation where required
    (e.g  xsd:choice....udt:AmountType...sdt:UBLAmountType...)

4. we are told that the case for substitution groups meeting a
requirement
    is that
a. they allow use of codes not in the supplied list
b. they do not require ripple changes of all the various Schema modules
c. by implication it seems that they are supposed to offer the above in
cases where
    validation is being allowed by use of XSD, since there would be no
point in
    them where XSD validation is not employed (since here you just
decide
    on a particular codelist and refer to its metadata in the code
metadata attributes)

5. Now suppose one has substitution groups in the codelist Schemas in
UBL 1.1:
as I read it (just studying the codelist papers and books like Wrox's
'XML Schema')
this would mean the following

where a validatable codelist exists in UBL 1.0 and an instance can only
have codes
of a certain known set of values,
a. in UBL 1.1 the same codes would be still 'UBL-valid' if they had any
values
b. the metadata attributes could describe the values allowed
c. the XSD would allow any such values
d. (here I get a bit out of my depth) what changes could be made to
Schemas
to still validate the required range of code values,
e.  i.e. maybe certain values could be made 'XSD invalid' locally in
specially
adjusted Schemas (without namespace changes)
f. even if e. could be done, the values which are 'local XSD-invalid'
would still be
'UBL-valid' since the substitution groups mechanism now allows any
values theoretically
g. to my mind it is then, in this UBL 1.1, improper to call any
particular code value in an instance
'invalid'
h. to my mind g. means that there is then less point including any
values in the Schemas of this UBL 1.1
i.  g. means the codelist Schemas with values become much more like
codelists without values (and hence
   without Schemas)
j.  i. means there is little point having the Schemas at all if they
have values which are substitutable or
    if they have no values at all
k. this leads to (almost?) the same solution we have in UBL 1.0 with the
codes which do not have codelist Schemas
l.  this seems to be no longer in keeping with the implied requirement
4c. above
m. it would seem there is more overhead for implementers with such a UBL
1.1 in that all code values now
have to be expected

but my most important concern perhaps is:
n.  there seems no way with this UBL 1.1 to actually reliably say that a
code value is *invalid* using XSD
o.   n. would appear to mean that either applications have to validate
the codes without XSD or they
      would be better keeping with UBL 1.0 where at least they know what
codes are invalid and which are not

Conclusion

6. So I don't see substitution groups offering anything other than a
subtle difference to just
scrapping validatable codes.
7. Furthermore they seem to make it impossible to ever validate
such codes using UBL XSDs.
8. To prevent 7. we'd be likely to want to have some codes which don't
use substitution groups but which do have Schema valdiation and
enumerated lists
9.   8. would probably involve the same codelists where we have
validation in UBL 1.0
10.  9. would be no different then from UBL 1.0 regarding these
codelists
11.  having a UBL 1.1 with Substitution groups would likely not actually
include any Schemas
       with that mechanism in UBL 1.1 if the requirements are to be met
anyway


If anyone has time and patience to follow all that and can reassure me
that substitutionGroups do offer UBL
codelists more than I give them credit for, please do.


All the best

Stephen Green



>>> "William J. Kammerer" <wkammerer@novannet.com> 22/02/05 02:47:13 >>>
I'm guessing that substitutionGroups mean "any extensions to the code
lists themselves cannot change in structure, only the enumerated sets
themselves can change," as the substituted element has either the same
type as the "head" abstract element - or one which can be derived from
it. I think that's the advantage of substitutionGroups over redefine;
there'd probably be nothing keeping you from changing the structure with
a redefine.

But in order for UBL to provide the (future) capability of "override,"
all the schemas for off-the-shelf code lists will probably have to be
modified to accommodate any possible future abstraction (kind of like
C++ virtual functions). I guess that's why the Code List group has to
make a decision now; and they won't know whether it's worth making these
changes unless someone can demonstrate how this substitutionGroup stuff
can be used.

William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320