Re: [ubl] Code list example document with Tims revisions accepted

[Anne Hendry <anne.hendry@sun.com>]

Hi Marty, Tim, David, and all,

I've attached here files, one for each of our 'standard' code lists,  
that contain values for each 'content' and 'name' components of the code 
list.  I had been given a template from lcsc for the format for these 
files, which can be seen in the CountryCode.txt file, but after seeing 
some of the recent discussion and examples I'm not sure it was the 
correct way to go about this, so for all the other code list 
content/name files I simply put the value for 'content' followed by the 
value for 'name' one per line, separated by a space, for each element of 
a code list.  This is the data that would then be taken by edifix and 
incorporated into the code list schema.

Marty, a couple of responses to some of your questions/notes in your 
latest posting:
- I'm not sure why it was decided (I wasn't in that meeting) that we 
should include a value for the 'name' component as well as the 'content' 
comopnent, but it does to me make sense to me to do this, as it is 
described in ccts as an alternate value for 'content' if needed.  It 
also helps to explain some of the codes that are only numeric, of which 
we had several, and had been looking for how to add additional 
descriptive information to those, and 'name' seems to work out well for 
this (even though 'name' in some of the code lists is actually more like 
a short description).  But so what's to note is that we now we have data 
values for that component, where we didn't for Beta.

- I'm not sure if the goal is to have values for all 9 of the ccts code 
list type supplementary comopnents, but I'm not sure where the 'name' 
component should be listed in the schemas.  It could rightly go in with 
the rest of the attributes.  Marty, you have a question next to this in 
the sample of the complex type generation - "Does this contain the code 
name in the instances?" - and I am wondering also whether when the 
decision was made to include this information, it was intended that this 
should show up in the instances, or is it meant to be kept with the rest 
of the supplementary information, separate from the actual code 
'content' value.

- Since some of these code values were made up by Stephen and myself 
(albeit with quite a bit of thought) before Beta, some of them are 
UBL-created and so didn't have anything to put in the 'name' part.  In 
such cases I made up something for most of them, but there are still a 
few (ChipCode, SubstitutionStatusCode, and OperatorCode) where I was 
really not clear if we needed a 'name'.  Also, I had the question as to 
why the OperatorCode only had multiply and divide.  It can't be the case 
that we want to limit our implementors to only those two arithmetic 
operations, is it?  Not being in that discussion, I'm just speaking off 
the top of my head here, but if this is how it should be, that's fine. 
 I just thought I'd ask for verification.  And speaking of verification, 
I have not double-checked these values, and should probably not be the 
one to do so, having make them, so I'd like to ask to have someone else 
check the correctness of these files (once they're finalized), but also 
now for the 'name' component of the ones I made up (longitude, latitude, 
line and document status, acknowledgement status,   (I also capitalized 
Multiply and Divide, since all other values seem to begin with caps.)

- Marty, in response to your latest document:
  + in your second para you say 'The first column in the table contains 
the UBL name and the second colulmn contains an example of the values 
for that name.  I think you mean the third column.
  + I'm not sure we need namespace prefixes any more; it was originally 
used to tie the code list catalogue to the rest of the models, but now 
that the codes are being modeled as bies, do we still need this prefix? 
  This and the two following components in Tim's ss (code list 
description and code list credits) are not part of the ccts cct type for 
code, and there is debate as to where these pieces of info should go. 
 Please check David's last email as he mentions he doesn't know what to 
do with these as they can't be added (extended) to the code cct supp 
comopnents (they cannot be attributes of the sdts).  In Beta we had 
these last two in the comment header block of each code list schema 
file.  They could also go in documentation /annotation, but you may be 
better to suggest where.
  + regarding cludt, yes it has already been removed in the latest 
schema drop  I'm not sure if someone is doing this, but we might as well 
create a new diagram that will eventually become part of the 
documentation, since there are already enough other questions about this 
to make it more problematic than helpful.  Lisa is working on getting 
some clarification, so she may be able to contribute to this.
  + under 'generate simple type' you have CodeName and have questions 
around 'CodeName' in the annotation documentation section.  My 
understanding is that we are including the value of 'CodeName' here to 
give meaning to the Code.Content values, especially when the 'Content' 
ends up being simple numbers, such as those 
AllowanceChargeReasonCode.txt, from the attached zip, for example.  Now, 
I'm not sure if the 'Name' component is expected to be available in the 
instance, but otherwise I'm also not sure why we would put it separate 
from the rest of the supplementary componetns otherwise.  It is a 
supplementary component, but one I think people would lwant to know far 
more often than they would want to know the others, and I'm not sure why 
this would be relegated to documentation when it is really part of the 
metadata of the code type.  It would be good from the UI point of view, 
and I think we did decide back in Montreal that info needed for UI type 
stuff coudl go into the documentation section (can someone verify this?) 
but I'm not sure that the other componetns are not as needed there, so 
we should probably thing about where this info is to end up.  The case 
for 'Name' staying the closest to 'Content' is high, though.

- I really don't know enough about how the structure of the schema 
effects the availability of the info in the instance, but it just seems 
to me that we are still not completely decided on:
a) what to do with the 'Name' component
b) what to put in the documentation section
c) how to store and make available the information in the 3 pieces of 
info that we had in Beta that are not accomodated by the ccts code list 
type supplementary components and which Tim has included in his sdt 
model: CodeListNamespacePrefix, CodeLsit Description, and CodeListCredits.

-Anne

Burnsmarty@aol.com wrote:

> All,
>  
> The attached document contains the complete example of code list 
> template for XMLSchema generation. It includes the recommended 
> modifications by Tim and has slightly cleaned up formating.
>  
> For those on the CLSC, if you are not getting all the email traffic on 
> this topic, this implements the model in our code list draft. This is 
> the document I was tasked with constructing at the CLSC conference on 
> Wednesday. Tim McGrath was kind enough to straighten out the data 
> model for me so that we could be consistent with the spread sheets. My 
> intention would be to move this example into the working document as 
> part of section 4.
>  
> Marty
>
>------------------------------------------------------------------------
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>

CodeContentandCodeName.zip