MHonArc v2.5.0b2 -->
ubl message
[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.
>
CodeContentandCodeName.zip
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]