[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Clarification of Ottawa Code List Deceisions (Was RE: (no subject ))
Greetings,
(Because we are now discussing interpretations of
decisions made as a group, I thought it best to include the whole
list.)
Good, now at least all of our assumptions have been
placed on the table (mine and Marty's). Let's see if we can reach agreement on
some of them.
Again, a refresher on the two types of code
lists from Ottawa:
a. Code lists that define codes used only in UBL (status codes, for example). Such lists are typically well-defined, are completely under our control, and are not (or should not be) extensible. b. Code lists that are defined by outside agencies and referenced in UBL. These are conceptually distinct from the first category even if some happen to be bundled into the UBL package. > I think that
regardless of whether it is a type a) or type b) code list, it needs to have a
data model and a schema in UBL. I think that the idea is to use genericode for
the data model and generate a schema for incorporation into the UBL schema
set.
> What I am suggesting is
that the data model and the schema's generated from it (Tony has the data modem
and which I have suggested a generated schema format for) become the
normative part of the UBL deliverables. Does everyone else agree that a schema for type-b code lists
should be required for UBL deliveries? Should it be
normative?
If a customizer needs to add a code to a type-b code list,
shouldn't they just add another 'Row' to the Genericode XML instance for that
list? They could then create a new schema, if desired, using the provided
stylesheet. Wasn't the difficulty in extending schemas one of the motivating
factors of the Ottawa decision?
> I might also point out that if
you accept that a user of UBL might want to customize a type b) code list, it is
hard to suggest that he be precluded from customizing a type a) code list since
both would be external to him.
When differentiating between the the two types of codes, the group
decided (assumed?) that type-a code lists "are completely under our
control, and are not (or should not be)
extensible". Does anyone disagree with this?
> The
distinction of UBL or non-UBL provides a perspective difference if its ours (UBL
committee) or theirs (third party). For a user its theirs or theirs, if you get
my inference
The distinction is those "that define codes used only in UBL
(status codes, for example)" and those
"that are defined by outside agencies and
referenced in UBL". This distinction is valid from any perspective,
particularly when we are talking about codes used in UBL
'documents'.
Also, if you haven't already done so, please revisit the Ottawa
discussions and decisions:
http://lists.oasis-open.org/archives/ubl/200508/msg00042.html http://lists.oasis-open.org/archives/ubl/200508/msg00060.html Thank You,
Mike
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]