OASIS Code List Representation TC

 View Only
  • 1.  RE: [codelist] notes and open questions in requirements

    Posted 10-12-2006 12:55
    
    
    
    
    
    My thoughts HGM> inserted below.
     
    Howard Mason


    From: Harris, Jim [mailto:jharris@ncsc.dni.us]
    Sent: 11 October 2006 19:46
    To: codelist@lists.oasis-open.org
    Subject: [codelist] notes and open questions in requirements

    We agreed in today’s teleconference that resolution was needed on some of the requirements that included notes and/or open questions.  These may or may not require changes to the requirement, but need to be reviewed to make that determination.  I have echoed the affected requirements below:

     

    R14 Metadata can have a particular simple type

    Metadata columns can have a defined data type.  The W3C XML Schema simple types are the default set, but a different datatype library can be specified (through the use of an identifying URI).

    Facets can be defined to restrict the data type (e.g. length, minimum/maximum, or pattern restrictions).

    Note: there is an option question around whether it should be possible to define the “type” of complex data (XML fragments) in some sense.

    HGM> Not a version 1.0 requirement

    R20 A code list can be derived from existing code lists by removing all common columns before aggregating the remaining columns

    It should also be possible to remove common keys as well as common columns.  A column cannot be removed unless all keys that it is part of are removed, and there aggregate must contain at least one key.

    Note: support for keys as well is columns is not yet implemented.

    HGM> Sensible requirement, which probably needs to be accommodated in the metadata even if the function is not implemented in 1.0

    R21 A derived code list can be required to contain a source code list as a row-wise subset

    Note: there is an open question about whether it should be possible to specify that only keys are compared, or that only particular keys are compared. 

    HGM>  Probably better to allow manual selection prior to integration - implementation of the integration service

     

    R22 A derived code list can be required to contain a source code list as a column-wise subset

    It should be possible to specify the subset via keys as well as via columns.

    Note: support for keys as well is columns is not yet implemented.

    HGM>  Non-critical

    R30 Each code list version has a unique identifier, different to the version-independent identifier for the code list

    The code list definition contains the version number (or string) as well as the unique identifier (a URI).

    Note: there is an open question around whether metadata-only code lists should be required to have explicit versions, especially for code lists where it is unlikely that the columns and keys will change over time.

    HGM>  Unlikely not= never, so need the option for specifiying versions

    R33 Sets of code list versions can be represented

    It must be possible to specify a “configuration” of versions of code lists that together form a coherent set for some purpose.

    Note: there is open question around whether it should it be possible to include a version-independent reference to a code list, instead of a reference to a particular version of a code list. 

    HGM> Essential requirement for reconstructing previous configurations of codelists, eg for contractual reasons. 

     

     

    This post is intended to prompt discussion (using the list) on these items.

     

    Regards,

    Jim

     

    =================

    Jim Harris

    Senior Court Technology Associate

    National Center for State Courts

    300 Newport Avenue

    Williamsburg, VA 23185-4147

    757-259-1804 tel

    757-564-2048 fax

    407-620-2335 cell

    jharris@ncsc.dni.us

    http://www.ncsconline.org

     

    ********************************************************************
    This email and any attachments are confidential to the intended
    recipient and may also be privileged. If you are not the intended
    recipient please delete it from your system and notify the sender.
    You should not copy it or use it for any purpose nor disclose or
    distribute its contents to any other person.
    ********************************************************************


  • 2.  RE: [codelist] notes and open questions in requirements

    Posted 10-24-2006 00:02
    Many thanks, Jim and Howard for posting and responding.
    
    Howard's observations resonated well with me when 
    he posted them ... would anyone like to add 
    anything new before tomorrow's teleconference?
    
    . . . . . . . . . . Ken
    
    At 2006-10-12 13:54 +0100, Mason, Howard \(UK\) wrote:
    >My thoughts HGM> inserted below.
    >
    >Howard Mason
    >...
    >
    >From: Harris, Jim [mailto:jharris@ncsc.dni.us]
    >Sent: 11 October 2006 19:46
    >To: codelist@lists.oasis-open.org
    >Subject: [codelist] notes and open questions in requirements
    >
    >We agreed in today’s teleconference that 
    >resolution was needed on some of the 
    >requirements that included notes and/or open 
    >questions.  These may or may not require changes 
    >to the requirement, but need to be reviewed to 
    >make that determination.  I have echoed the affected requirements below:
    >
    >R14 Metadata can have a particular simple type
    >
    >Metadata columns can have a defined data 
    >type.  The W3C XML Schema simple types are the 
    >default set, but a different datatype library 
    >can be specified (through the use of an identifying URI).
    >
    >Facets can be defined to restrict the data type 
    >(e.g. length, minimum/maximum, or pattern restrictions).
    >
    >Note: there is an option question around whether 
    >it should be possible to define the “type” of 
    >complex data (XML fragments) in some sense.
    >
    >HGM> Not a version 1.0 requirement
    >
    >R20 A code list can be derived from existing 
    >code lists by removing all common columns before 
    >aggregating the remaining columns
    >
    >It should also be possible to remove common keys 
    >as well as common columns.  A column cannot be 
    >removed unless all keys that it is part of are 
    >removed, and there aggregate must contain at least one key.
    >
    >Note: support for keys as well is columns is not yet implemented.
    >
    >HGM> Sensible requirement, which probably needs 
    >to be accommodated in the metadata even if the 
    >function is not implemented in 1.0
    >
    >R21 A derived code list can be required to 
    >contain a source code list as a row-wise subset
    >
    >Note: there is an open question about whether it 
    >should be possible to specify that only keys are 
    >compared, or that only particular keys are compared.
    >
    >HGM>  Probably better to allow manual selection 
    >prior to integration - implementation of the integration service
    >
    >R22 A derived code list can be required to 
    >contain a source code list as a column-wise subset
    >
    >It should be possible to specify the subset via keys as well as via columns.
    >
    >Note: support for keys as well is columns is not yet implemented.
    >
    >HGM>  Non-critical
    >
    >R30 Each code list version has a unique 
    >identifier, different to the version-independent identifier for the code list
    >
    >The code list definition contains the version 
    >number (or string) as well as the unique identifier (a URI).
    >
    >Note: there is an open question around whether 
    >metadata-only code lists should be required to 
    >have explicit versions, especially for code 
    >lists where it is unlikely that the columns and keys will change over time.
    >
    >HGM>  Unlikely not= never, so need the option for specifiying versions
    >
    >R33 Sets of code list versions can be represented
    >
    >It must be possible to specify a “configuration” 
    >of versions of code lists that together form a coherent set for some purpose.
    >
    >Note: there is open question around whether it 
    >should it be possible to include a 
    >version-independent reference to a code list, 
    >instead of a reference to a particular version of a code list.
    >
    >HGM> Essential requirement for reconstructing 
    >previous configurations of codelists, eg for contractual reasons.
    
    
    --
    UBL/XSLT/XSL-FO training: Allerød/Vårø Denmark 2006-11-13,17,20/24
    UBL International 2006  2006-11-13/17 http://www.ublconference.com
    World-wide corporate, govt. & user group UBL, XSL, & XML training.
    G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
    Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
    Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
    Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
    Legal business disclaimers:  http://www.CraneSoftwrights.com/legal