Paul,
Thanks for giving this a thorough read. With the help of eyes like yours,
we will rapidly converge on a final set of requirements and their expositions,
as well as a conforming design.
Cheers,
Marty
In a message dated 2/11/2004 6:33:27 AM Eastern Standard Time,
paul.spencer@boynings.co.uk writes:
Marty,
Many thanks for your comments. I have a
few in return. I have numbered them according to the [Rxx] numbers in your
reply.
[R32] This is important, but does not
address this issue. However, I think other things (the use of a unique
namespace URI for each version) will make this OK.
You are saying that your requirements are met but by this one in
conjunction with others. do I follow you?
Correct.
[R17] It is not clear whether this URI
is the namespace URI or the schema location. It needs to be the namespace
URI. This should be explicitly stated. If you meant the schema location,
then I think there is a problem, since this is not a persistent
identifier.
Sounds right. Can you propose a revised content for this requirement's
text?
"(1) - any two
uses of the same namespace URI represent the use of the same code
list
(2) - no two differing
code lists shall be represented by the same namespace URI"
Basically, I have just
added the word "namespace". However, I wondered what the word "definition" was
doing in there, so I left it out :-) To me, a "code list" is a complete
list, a "code list definition" is a single entry in that list. This might not
be the "official" interpretation, but if there is scope for confusion, I saw
no harm in leaving the word out.
Not related to the Government
requirements, and referring to the Feb 8 document:
I thought [R19] was being
removed.
To preserve the original author's notion, I kept it but said it needs to
contain 2 or more. You may be right that it should be removed as a
requirement. Bring this up on the call tomorrow and we will do
it.
[R25] Do you mean "must contain"? Or
must it be possible for it to contain (i.e. the code list schema contains an
optional element)?
I think you are correct here. Lets confirm this on the conference call
too.
[R26] directly contradicts [R18]. It
would not if you were referring to the code list mechanism allowing this to
be implemented when required. I am beginning to wonder if there is some
confusion between the requirements for a mechanism for defining code lists
and the requirements of the code lists themselves.
I think both are valid. Users may want to extend or restrict code lists.
Code list designers may, on occasion, want to prevent extension. For example,
in Schema this can be achieved by marking a definition as final.
I agree with the
intention. However, to me, [R26] says that each list must make it possible to
extend or restrict it. We are saying that the code list mechanism must allow
this, then developers of lists will decide whether to allow it or
not.
Unless I have misread the schema, we
seem to have switched from defining codes as complex data types to defining
them as elements. This means that we must always use the name defined in the
code list schema. We can therefore not use a <PurchaseCurrency> or an
<InvoiceCurrency> using terms from a currency code list. Have I
misread this?
I believe so. THe schemas are defined as elements with a complex type.
The definitions in this mapping section are required to enable extensibility
of code lists for which we have found no other working mechanism in W3C
Schemas.
I think it is possible
to change the element name by defining a new substitution group in the schema
using the code list, so perhaps this is OK. Some better examples might help (I
think the one you have is not valid because of an extraneous element at the
end). I also don't think your schema meets the requirements of [R22]
or [R25].
I know I am in danger
of being asked to do this, but I have already spent several hours on this and
unfortunately don't really have the time for a full day's unfunded work
at the moment.
Regards
Paul
Paul,
I believe we have alrady captured these requirements as noted below.
Please see if there needs to be a change in wording to make this
clearer.
Hope this helps,
Marty
In a message dated 1/28/2004 3:25:31 PM Eastern Standard Time,
paul.spencer@boynings.co.uk writes:
As requested at today's telecon, these are the requirements
extracted from
my position paper on codelists that was recently
uploaded.
Support long-term archiving of
documents
----------------------------------------
Many documents
require long-term archiving. To achieve this, the documents
must be
able to indicate the version of a code set that is in use.
They
should do this both in the code list reference in the instance
document (so
the correct set is accessed) and in any document
metadata (so that the code
list(s) required can be archived with the
document).
Versioning
----------
A code list must indicate
its version number. It may also provide dates
between which it is
valid. A reference to a code list must indicate the
version to which
it refers.
(1) - any two uses of the same URI represent the use of the
very same code list definition
(2) - no two differing code list definitions shall be
represented by the same URI
The business issue is that when two trading partners identify
the use of a code list, there
must not be any ambiguity. Should either partner create a code list
or change an existing code list, the identification of the resulting code
list must be distinct from that of its origin.
Looking up Code
Meanings
------------------------
It must be possible to find the
meaning of any code in the code set.
Each code
value on the code list must not only contain valid values and decode
values, but must also contain a long description which describes, in
detail, the business meaning and usage for this code
value.
Multiple definitions (e.g. short and
long)
------------------------------------------
The mechanism
used for holding code sets must support multiple
definitions.
Specifically, it must be possible to hold both a short
description, a long
description and a symbol (with information on the
correct positioning of the
symbol relative to the
value).
Each code
list must have the flexibility to have additional descriptive information
added by an individual user to account for unique business
requirements.
Each code
value must have the flexibility to have additional descriptive information
added by an individual user to account for unique business
requirements.
Multi-lingual
-------------
The mechanism used
for holding code sets must support extracting information
in multiple
languages.
Perhaps not a perfect fit for this, but the following requirement
facilitates: [R30] and [R31].
Must be able to carry both a code and (optional)
value in the
message
---------------------------------------------------------------------
A
requirement in the health service (and possibly elsewhere) is that both
a
code and a meaning can be carried in a document. As an example of
the use of
this, if a person selects a value from a drop-down list on
a web page, the
text selected as well as a code describing it must be
transmitted to health
systems for audit purposes, even though the
receiving application might
ignore the text and use the indicated
code list to look up a meaning.
I think this is covered by [R25] above or in the usage of code lists
in
As
first-order business information entities (BIEs). For example, one
property of an address might be a code indicating the country. This information appears in an
element, according to the Naming and Design Rules specification [NDR]. For
example, in XML a country code might appear as:
<Country>UK</Country>
As
second-order information that qualifies some other BIE. For example, any
information of the Amount core component type must have a supplementary
component (metadata) indicating the currency code. For example, in XML a
currency code might appear as an attribute:
<Currency
code=”EUR”>2456,000</Country>
These are the main requirements, and so the most
important part. The rest of
the document goes into detail including
proposing a syntax.
Regards
Paul
Spencer
Director
Boynings Consulting
Ltd
http://www.boynings.co.uk