[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Code list example document with Tims revisions accepted
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]