[
Lists Home |
Date Index |
Thread Index
]
Ken,
its been a while since I have had a chance to catch up, so hi.
I have been re-reading your UBL Code List Value Validation Methodology (v0.4) again while I've had a few days off (I know I need to get out more :-), a few questions if I may be so bold :-
1. How has this work been received in UBL. Is it proceeding as planned. Do you think there will be any statement on adoption of this methodology any time soon ?
2. A genericode file contains ONE code list at ONE version right ??
3. In the doc you state that when an enumeration appears WITHIN a schema, TPs may ligitimately operate a subset since all values are valid in the full set, but they may not add new values. Am I correct in assuming that the same is true for a code list which is defined by a standards organisation (not UBL) but which is NOT embedded within schema ?
As you know in my situation we operate code-lists than are defined by a standards body and in most cases want to use them in all situations where there are equivalent semantics (including internal app integration) rather than create alternative bespoke lists.
Problem is, we do sometimes want/need to extend these lists often to provide higher fidelity mapping to our operational systems. Another example might be where a code identifies some high level semantic, but we want to be able to create a bunch of 'sub' codes to provide a more granular view - accepting that in 2-way translation there will be data loss. Lobbying the standards body and getting a timely change/addition can be problematic ? - anyway - I digress
4a. For code lists where there is no established [complete and/or definative] standard or where the semantics and values are TP relationship specific, the set of permissible values can be extended and/or restricted from an offered base set (if available - using your DocumentStatusCodeCodeType example) or the participating organisations can agree the set of values (and presumably the list ID to be used in XML instances). Is this correct ?
4b. If I have many TPs and each has a slightly different relationship, might this cause me to need a separate genericode file for EACH code list that differs, however slightly, from another ?. Is there a suggested low maintenance approach to this problem ?
4c. Similarly to (4b.), if a custom code list is shared across service contracts for multiple TP relationships, but a need arises to create a new version with [say] some values added or removed, and we need to be able to operate both versions concurrently for some period of time, does this require a complete re-statement of the new code list (in a new .gc file) with a new version number even if the difference is ONE codified value (added/deleted/changed) amongst a set of 10,000 values ?
This also means that the implementation will repeat a lot of code. I guess I am wondering whether there is/should be a way of expressing a 'delta' of values ?
5. Continuing the theme of (4), we have some code lists which are both highly volatile (values added and deleted (rarely changed) every month) and are very large (e.g. > 50000 entries). An example is Vehicle Make/Model. Do you think this approach is suitable for this type of reference data (multiple 'active' versions, large number of values) ?
6. Can you explain the difference between the UBL 'CodeType' and 'IdentifierType' in terms of what circumstances you would use either ?
If a schema identifies the ListID, but we want to use a different one (to employ as 'richer set' of values) , how would an industry standard schema accomodate this possibility such that the schema remains a standard and unchanged definition of the structural constraints (is this the CodeType/IdentifierType approach) ?
7. Do you think that a skeleton context association file could be auto-generated ?
8. Changing tack slightly. I am interested in using genericode files for a number of purposes including, value-based validation, UI generation (e,g, to populate UI controls such as list boxes), transcoding between application specific codes. It would appear from the genericode materials that this would be feasible, do you agree ? :-
Std Code Std Desc Appl'n A Equiv Appl'n B Equiv UI Text
(key) (key) (key)
abc Std Widget def ghi Part No 3321-7 (small widget)
9. What is the suggested approach to deal with deprecated code values. Is this considered as a versioning issue both for standards based code-lists (embedded in schema or not) and custom code lists ? Should code lists include validity date/time values or other 'active/deprecated' indicators ?
10. Caller assertion of list version. If there is no matching version is it best to flag the validation failure (and possibly reject the message) - that is, 'trust' the caller assertion, or validate against the un-vesioned complete list (similar point to the one we discussed earlier about whether to to an xsi:schemaLocation attribute value) ?
11. Devils advocate: Whats the difference in having to distribute the latest .gc file versus having to use the latest XSD with updated embedded enums ? (Ok, I think I know the answer to this one, but it would be good to have a quote from 'championing' designer, for the benefit of my peer group and sceptical and untrusting bosses :-)
Cheers
Fraser.
Anthony: So that you are aware, I am attempting to stimulate interest in the use of genericode within the organisation that I work with (a large UK financial services company) from a number of potential perspectives. One of these is value-based validation, hence discussions with Ken
i.r.o his work with UBL, but also for a more broadly accessible resource for reference data used for a variety of purposes such as UI generation, transcoding, etc..
| 