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

[Tim McGrath <tmcgrath@portcomm.com.au>]

just to fill in the gaps....

Anne Hendry wrote:

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

this was not so much decided formally as it just became a natural 
consequence of recognise the true structure of the CodeType in CCTS.  as 
you say, it would be hard to say why we shouldn't do this.

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

the question was mine - and i just wanted to understand what this 
attribute would have in it.  having seen stpehen's examples, i know 
understand this would be the Code.Name for the instacne of Code.Content 
in the element.

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

its because these are really not codes but a means by whcih we can 
enforce a contrained set of values by using an enumerated list.  as such 
the Code.Content is the same as Code.Name.  i suggest we just duplicate 
them.

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

Sue has volunteered to do this - can you make sure she sees them.  also 
if you send a set to the LC list we can review before this week's call.

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

yes i think we do to ensure we dont have conflicts.

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

it was discussed and we had agreed that these need not appear in the 
schemas at all (apart from namepsace prefix which appears because it is 
used).  however if someone feels they needs to be in schema 
documentation, i could accept this.  it is not significant that they are 
not CCT supplemntary components - they are UBL extensions for modeling 
semantics and providing schema support. (like we also have 'examples' 
and other none CCTS metadata.)

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

i attach an idea for how this may end up.  obviously, whoever owns the 
original visio diagram needs to make the actual edits.

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

once again, i take responsibilty for the ??? and the reference to 
CodeName.  
firstly, the ??? relates to the fact i dont know what namespace prefix 
this would have (although i suspect it is "ccts:")  i was hoping some 
more XSD aware person might fill this in.
secondly, CodeContent and CodeName need to be at the same level in our 
enumeration because one CodeContent has one CodeName.  the other 
supplementary components are actually part of CodeList which is a parent 
to Code (ie a CodeList has many Codes).  So if we tried to put a 
CodeName with these components we would know which one of the set to 
use.  it is like these two are pairs in the text files you are building 
- the whole set of pairs share the same CodeList components.
the syntax of xsd:enumeration allows for an xsd:annotation along with a 
value, so this is the only place to put the CodeName.  in fact, it is 
still documentation - just not in the same place as the other 
components.  this example (provided the syntax is correct) appears to do 
all we want.
PS in the document instance the CodeName can appear as the value of an 
attribute of the element with a value of CodeContent..

>
-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160