Re: [ubl-ndrsc] Code list rules document

["Eve L. Maler" <eve.maler@sun.com>]

I like the kind of feedback where most of the comments start out with 
"It's good...". :-)  Here are some specific responses; I hope to crank 
out a revision in a week or so:

Burcham, Bill wrote:
> 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?

Originally I introduced the terminology because I anticipated that we 
would need to give rules on how to do a code list module for the 
second-order case.  But later we decided not to get into rules for that, 
because it's too complicated to explain to that audience (and we don't 
know what the right answer is yet).  I used to have an "ISSUE:" in there 
that mentioned the second-order codes, but took it out because of the 
decision not to go there.  Perhaps this needs a note explaining why the 
second-order case isn't treated (yet?).

> 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.

Will do.

> 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.

Test?  What, are you kidding me? :-)

I didn't test the UNECE schema because its purpose is to formally define 
a code list, not to be directly usable with instances (that is, as far 
as I understand it there will never be an instance conforming to the 
UNECE schema).  However, I didn't think to question their actual list of 
enumerations; is this the problem you ran into?  I figured that this is 
precisely the domain of a code-list-maintaining agency, and we have to 
assume their list is normative.  I didn't include the whole list in the 
template because that wasn't the purpose of the template.

> 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.

And heck, maybe at some point UBL will change its mind and want such 
foreign global elements too.

> 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?

Because the derivation opportunities sections were just a convenient way 
to explore the consequences of XSD derivation rules.  While these 
explorations contributed to an understanding of how to score the context 
rules friendliness (making some assumptions about how those rules would 
work, of course), it didn't seem right to base any scores directly on 
derivation solutions.

Thanks for looking so carefully at this!

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com