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