Re: [ubl] UBL 1.1 Code List Requirements Review

MHonArc v2.5.0b2 -->

















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




From: Tim McGrath <>
To: 
Date: Wed, 16 Feb 2005 11:31:44 +0800










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
 



Note that the [5] is the  rating I gave to this requirement.
 

 
 
2.2.2     [Rating:  ]  [R2] Second-order
business information  entities
 




Note that the [5] is the  rating I gave to this requirement.

This is becasue the current ebXML CCTypes have implemented supplementray
components as attributes, not because of any theoretical requirement.


 

 
 

2.2.3     [Rating:  ]  [R3] Data
and Metadata model separate from  Schema representation



 




Note that the [5] is the  rating I gave to this requirement.



2.2.4     [Rating:  ]  [R4] XML
and XML Schema  representation
 




Note that the [3] is the  rating I gave to this requirement.

Different XML NDRs will mean not all users of the model adopt the schemas
provided.





2.2.5     [Rating:  ]  [R5 (Future)]
Machine readable data  model





Note that the [5] is the  rating I gave to this requirement as
stated.

However, the example is misleading.  the example relates to presentional
format of the number - not really a code issue.  I think what you meant to
show was machine readable model not machine readable value.  






 
2.2.6     [Rating:  ]  [R6 (Future)]
Conformance test for code  lists





Note that the [5] is the  rating I gave to this requirement.




 
2.2.7     [Rating:  ]  [R6a] Supplementary
components or metadata  available in instance documents





Note that the [1] is the  rating I gave to this requirement.

If you want validation use a schema or maintain independant validation mechanisms
- this approach seems like the worst of both approaches.  the maintenance
problems of synchronizing code sets with the overhead of duplication!






 
2.3         Types of code  lists
 
2.3.1     [Rating:  ]  [R7] UBL maintained Code  List





Note that the [5] is the  rating I gave to this requirement.

It is sad but true - however, these should be kept to a minimum.






 
2.3.2     [Rating:  ]  [R8] Identify and use external standardized code  lists





Note that the [5] is the  rating I gave to this requirement.

However, i hope by "use" you mean "reference".  There are really two situations:
 UBL "uses" a code list by incorporating it into the library (as we do now
with currency code) and UBL "references" a code list by pointing off to some
other source. The latter may be what you implied in the previous requirement
[R7] but i think it belongs with this one .  It is a question of who owns
the information.  So perhaps we need to make this two separate requirements.






 
2.3.3     [Rating:  ]  [R9] Private use code  list





Note that the [5] is the  rating I gave to this requirement.

In this requirement it may help to distinguish between private code lists
that are used by specific agreement between two parties (e.g. set in their
ebXML CPPA) against those that are customizations of [R8] code lists for
use in specific contexts.






 
2.4         Technical requirements
of Code  Lists
 
2.4.1     [Rating:  ]  [R10] Semantic
 clarity



Note that the [5] is the  rating I gave to this requirement.

Who could argue against this?  the issue (as you state it) is the mechanism
and that is not a requirement - it is a solution.  what the requirement needs
to say is that we need a mechanism to extend the intension of the values
in the code list.  i think that is what you meant by "de-rerefence".






 
2.4.2     [Rating:  ]  [R11]  Interoperability





Note that the [5] is the  rating I gave to this requirement.

Interoperability is the requirement and validation is a solution.






 
2.4.3     [Rating:  ]  [R12] External
 maintenance





Note that the [5] is the  rating I gave to this requirement.

I would add "create and maintain" to this requirement.






 
2.4.4     [Rating:  ]  [R13]  Validatability





Note that the [0] is the  rating I gave to this requirement.

It is a solution not a requirement.






 
2.4.5     [Rating:  ]  [R14] Context
rules  friendliness



 




Note that the [?] is the  rating I gave to this requirement.

what has NDR to do with context rules? do you mean UBL Context Methodology?
Or should this be called NDR Compliance requirements?  It seems like the
title and the description don't line up.





2.4.6     [Rating:  ]  [R15] Upgradability
/ Extensibility without  modifying underlying references





Note that the [?] is the  rating I gave to this requirement.
At oen level i thought this meant - must be able to change to different/new
code lists.  why would you want to change underlying source of the previous
one?  i am confused.






 
2.4.7     [Rating:  ]  [R16]  Readability





Note that the [1] is the  rating I gave to this requirement.

Just in case i have to look at an example.
:-) 

But lets not mislead anyone that people (except us) will read these things.
 If they have to - we have failed!






 
2.4.8     [Rating:  ]  [R17] Code
lists must be unambiguously  identified





Note that the [5] is the  rating I gave to this requirement [up
to an including line 43].

There are two sets of requirements here.  One to require umambiguous identification
and another set of 4 that require how URIs are to be used.  They should not
be put together.  URI may be a solution for [R17] but it doesn't mean their
requirements are linked.






 
2.4.9     [Rating:  ]  [R18 (Future)]
Ability to prevent extension or  modification





Note that the [0] is the  rating I gave to this requirement.

I agree this is not a requirement on the model.  It is an implementation
option. The owners of code lists can choose not to extend or modify their
code lists.  I can think of no case where anyone would want to.






 
2.5         Design Requirements
of Code List Data  Model
 
2.5.1     [Rating:  ]  [R19] A set
of the values (codes) forms each  code list
 




Note that the [?] is the  rating I gave to this requirement.

Can you give an example of a code list with no specific predefined values?
 I thought a code list was a set of predefined values.





2.5.2     [Rating:  ]  [R20 (Future)]
Multiple lists of equivalent  values (codes) for a code list





Note that the [0] is the  rating I gave to this requirement.

This is confusing what is a code with its extended values.  in the data model,
the code value is always unique  it may have extended values as attributes
that give other information (such as "S" or "the day of rest in the christian
calendar") but the code is the key.  there can be several codes such as "0","SUN","Sun","Sunday","DIM"
or with ISO3166-alpha and ISO3166-numeric for country codes.  




 
2.5.3     [Rating:  ]  [R21] Unique
identifier(s) for a code  list



Note that the [5] is the  rating I gave to this requirement.

But it seems to repeat R17.






  
2.5.4     [Rating:  ]  [R22] Unique
identifiers for individual  entries in a code list



Note that the [5] is the  rating I gave to this requirement.

This is what should have been R20.





2.5.5     [Rating:  ]  [R23] Names
for a code  list



Note that the [5] is the  rating I gave to this requirement.

Can't unique name also be a unique identifer [R21].






 
2.5.6     [Rating:  ]  [R24] Documentation for a code  list



Note that the [5] is the  rating I gave to this requirement.




 
2.5.7     [Rating:  ]  [R25] Documentation
for individual entries on  a code list



Note that the [5] is the  rating I gave to this requirement.

It is not just documentation it is extending (or supplementary) values that 
convey more information.  The requirements should not specify what they are. 





 
2.5.8     [Rating:  ]  [R26 (Future)]
The ability to import, extend,  and/or restrict values and elements of other
code  lists


 



 
Note that the [5] is the  rating I gave to this requirement.

 
 


2.5.9     [Rating:  ]  [R27 (Future)]
Support for describing code  lists that cannot be enumerated
 



 
Note that the [2] is the  rating I gave to this requirement.

 
 


2.5.10       [Rating:  ]  [R28 (Future)]
Support for references to  equivalent code lists
 



 
Note that the [3] is the  rating I gave to this requirement.

 
 


2.5.11       [Rating:  ]  [R29 (Future)]
Support for individual values  to be mapped to equivalent values in other
code  lists


 
Note that the [5] is the  rating I gave to this requirement.

 
 



 
2.5.12       [Rating:  ]  [R30 (Future)]
Support for users to attach  their own metadata to a code list


 
Note that the [3] is the  rating I gave to this requirement.

 
 



 
2.5.13       [Rating:  ]  [R31 (Future)]
Support for describing the  validity period of the values
 



 
Note that the [5] is the  rating I gave to this requirement.

Different version would be different codes lists and therefore be uniquely
identifiable as such.

 
 


2.5.14       [Rating:  ]  [R32] Identifier for UN/CEFACT DE  3055.


 
Note that the [2] is the  rating I gave to this requirement.

This is actually a solution for R21 and R23 not a requirement.

 
 





 





 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.
 
  
 
  
 
  
 
  
 
  
 
  
  
  
  
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.