RE: [ubl] Code list value validation methodology (version 0.3)

["Vint, Dan" <DVINT@acord.org>]

below

> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
> Sent: Tuesday, January 24, 2006 9:08 PM
> To: Universal Business Language
> Subject: Re: [ubl] Code list value validation methodology (version
0.3)
> 
[snip]
> 
> Partially, but there is a dependency issue that might impose some
> changes on how we declare code lists in the schemas.  Consider that
> my proposed methodology requires an instance to first pass the
> official UBL W3C Schema constraints in order to confirm that all of
> the information items are correctly in place structurally in an
> instance before it can be run against a code list context association
> file to check the values in those places.
> 
> Since the UBL enumerations would not include the extended values, an
> instance wouldn't pass the first step before the value validation is
> executed.  If we can't run the first pass, the integrity of the
> second pass is in question, so I think the run of the first pass is
> mandatory.  Hence the problem.
> 
> However, if we changed the way UBL declares code lists to be defined
> solely on a lexical basis without any enumeration of any values (very
> radical suggestion and probably not palatable to many people), then
> not only would the code list context association file work for all
> code lists for all sets (public, private, restricted, extended,
> alternative, etc.), but it would end up probably being a mandatory
> step in the validation, not an optional step.  I have no problems
> with this from a geek's perspective of ensuring the values are
> correctly defined for trading partners at the end of all validation
> processes (a basic tenet of Document Schema Definition Languages
> (DSDL), but it might be considered heretical by some that value
> enumerations not have any role in the schema expressions.  The schema
> expressions end up being solely structural validation, and the code
> list context association files end up satisfying all requirements for
> value validation.  I personally don't think that is a problem, but
> many people might have strong opinions that schema-expressed
> enumerations are sacrosanct and necessary.

[snip]

I haven't followed all the details on code lists and validation, but I
can say that at ACORD we have two camps. We have one group that wants
the validation in the schema and another that just wants to deal with
them in code or else where. We also have the requirement to both extend
and restrict any code list except those that we might declare closed
(very few of these).

In our first version we published two versions of our schema, one with
and the other without enumerated values. Our latest thoughts are to
publish the schema as a base schema with no enumerations and the second
schema as a redefinition of just the oode lists. 

I'm curious as to the UBL thoughts on general validation in a production
environment. I have many members indicating they will use the schema to
test and develop their environment, but that they will not be using
validation in the final production - are you finding the same split?

..dan