Here's my feedback:
1. 117-124 first and second-order code lists are introduced.
The section goes on to give some detail about first-order code lists and their architecture -- but nothing further is said about second-order ones.
Was this on purpose or just an oversight?
2. It's good that we've got an early section (3.2) specifying the correspondence between our representation and ebXML's.
The table in section 3.2 is extremely valuable.
Small point -- that table should have a caption (with number) for reference.
3. It's really good that you're using the ISO 3166-1 code list for illustration.
Makes the work so much more defensible than it would otherwise be (if we chose to use a hypothetical).
Question: does it actually work?
i.e. did you actually test the proposal with the UNECE schema and the "template" and create instance documents to see if valid documents are validated and invalid ones are flagged as such?
(I ask, since the illustration starting on line 210 has shorthands for readability).
Reason I asked is 'cause I tried it for a few minutes the other day and ran into some validation problems with the UNECE schema.
4. line 314.
It's good that you expunged all the uses of global elements from the architecture, yet let the audience know that they could define their own global elements all they want.
5. In section 4 "Rationale" each contender is evaluated against the requirements listed in section 4.1.
For each contender in section 4.2 there is a section entitled "Derivation Opportunities" (these are in sections 4.2.*.3).
Why is not "derivation opportunities" one of the "requirements" listed in section 4.1, scored in sections 4.2.*.4, and contributing to the total scores given in section 4.3?
