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] UBL 1.1 Code List Requirements Review


Please find my comments belows.  

Keep up the good work. This paper is going to be an invaluable resource for anyone designing or implementing business document exchanges.

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.


 



Burnsmarty@aol.com wrote:
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

e burnsmarty@aol.com


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476



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