[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Fwd: UBL 1.1 Code List Requirements Review - [resent unwrapped]
Code List Enthusiasts: We are working on the implementation of
the requirements for a Universal Business Language (UBL) 1.1 version of the
code list specification. At the end of the UBL 1.0 process, some of the
proposed solution components were not approved. The reason for this was that
there was a desire by the greater UBL committee to obtain better clarification
/ justification for the requirements set, and, the review of specific concerns
with the detailed solution proposed. The efforts of ROSETTANET, OAGIS, UBL,
and AEX/CFI (see sourceforge.net/projects/aexdev and
sourceforge.net/projects/cfidev), have all considered models for code lists (as
well as many other groups). These groups listed have expressed a specific
interest in the possibility of a collaboration to achieve a single
specification that all can use. For this reason I am circulating this email
widely recognizing that the present effort is being conducted under the
auspices of the OASIS UBL committee. To facilitate the discussion, I undertook
an exercise as the editor with some help from a couple of discussions with
other participants to try and clarify the requirements in the document. At this
time, we want to conduct a canvas of interested parties to obtain some degree
of support for the requirements for code lists. We have not added or deleted requirements
to date. We have only massaged the wording so that they were more
understandable -- this will necessarily be a continuing process.
Also, I would point out that the current set of requirements include those
collected from the participation of all the UBL code list contributors and not
a single view. I have taken my role as editor as that of aggregating
requirements and not passing judgement on them. That being said, I believe the next step
will involve obtaining some measure of support for the requirements by
providing an email response that allows the reader to provide their judgement
on a scale of 0-5 (0=not supported, 5=highly supported, X=no opinion, ?=I don't
understand this). During that canvas we will try to obtain the specific
concerns with the proposed model(s) for further resolution. Please review the attached draft (only so
far as section 2 requirements). Then, please reply to this email with an
indication of support for the inidividual requirements. For example, consider
the requirement R1. Below is a annotation of the list below for that requirement
with an optional comment added: 2.2.1 [Rating:
5][R1]
First-order business information entities Note
that the [5] is the rating I gave to this requirement. Here is
a comment about the proper way to state this requirement ............. Please add your ratings to the [Rating: ] annotation of the requirements below. If
you desire to comment further, simply type after the requirement. Use a rating scale of 0-5 (0=not supported, 5=highly supported, X=no opinion,
?=I don't understand this) UBL Code List 1.1 Requirements Summary: 2.2 Use and management of Code Lists 2.2.1 [Rating:
][R1]
First-order business information entities 2.2.2 [Rating:
][R2]
Second-order business information entities 2.2.3 [Rating:
][R3]
Data and Metadata model separate from Schema representation 2.2.4 [Rating:
][R4]
XML and XML Schema representation 2.2.5 [Rating:
][R5
(Future)] Machine readable data model 2.2.6 [Rating:
][R6
(Future)] Conformance test for code lists 2.2.7 [Rating:
][R6a]
Supplementary components or metadata available in instance documents 2.3 Types of code lists 2.3.1 [Rating:
][R7]
UBL maintained Code List 2.3.2 [Rating:
][R8]
Identify and use external standardized code
lists 2.3.3 [Rating:
][R9]
Private use code list 2.4 Technical requirements of Code Lists 2.4.1 [Rating:
][R10]
Semantic clarity 2.4.2 [Rating:
][R11]
Interoperability 2.4.3 [Rating:
][R12]
External maintenance 2.4.4 [Rating:
][R13]
Validatability 2.4.5 [Rating:
][R14]
Context rules friendliness 2.4.6 [Rating:
][R15]
Upgradability / Extensibility without modifying underlying references 2.4.7 [Rating:
][R16]
Readability 2.4.8 [Rating:
][R17]
Code lists must be unambiguously identified 2.4.9 [Rating:
][R18
(Future)] Ability to prevent extension or modification 2.5 Design Requirements of Code List Data Model 2.5.1 [Rating:
][R19]
A set of the values (codes) forms each code list 2.5.2 [Rating:
][R20
(Future)] Multiple lists of equivalent values (codes) for a code list 2.5.3 [Rating:
][R21]
Unique identifier(s) for a code list 2.5.4 [Rating:
][R22]
Unique identifiers for individual entries in a code list 2.5.5 [Rating:
][R23]
Names for a code list 2.5.6 [Rating:
][R24]
Documentation for a code list 2.5.7 [Rating:
][R25]
Documentation for individual entries on a code list 2.5.8 [Rating:
][R26
(Future)] The ability to import, extend, and/or restrict values and elements of
other code lists 2.5.9 [Rating:
][R27
(Future)] Support for describing code lists that cannot be enumerated 2.5.10
[Rating: ][R28
(Future)] Support for references to equivalent code lists 2.5.11
[Rating: ][R29
(Future)] Support for individual values to be mapped to equivalent values in
other code lists 2.5.12
[Rating: ][R30
(Future)] Support for users to attach their own metadata to a code list 2.5.13
[Rating: ][R31
(Future)] Support for describing the validity period of the values 2.5.14
[Rating: ][R32] Identifier for UN/CEFACT DE 3055. Marty Burns, Hypertek, Inc. For NIST p 1(301)315-9101 c 1(301)257-9101 From:
Burnsmarty@aol.com [mailto:Burnsmarty@aol.com] |
wd-ublclsc-codelistReqs-20050117.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]