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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

 

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



http://www.ncsconline.org