search

tracefirst / usaha_committee

XML schema for electronic CVIs
8 stars 2 forks source link

State and Herd Disease Status #28

Closed mkm1879 closed 7 years ago

mkm1879 commented 10 years ago

How do we plan to map State and Herd disease statuses? Same question for general statements required.

mmcgrath commented 10 years ago

OK -- let me go with a "soft" suggestion to gauge reaction -- we could add a set of name/value pairs to capture data such as this that eCVI generators may have and want to include in the doc. For example, we could add an element called metadata with a name and value (chosen from int, string, float). I fear an unending list of things for discussion if we want to "elevate" every possible piece of data to an attribute/element in the schema......

mkm1879 commented 10 years ago

I was going to make an argument for this based on the need for these a part of import regulations, etc., rather than traceability. But in discussion with Dr. Parr, our state vet, the places where we rely upon the issuing vet to know an area or herd "status" is really changing from formal "status" to more the kind of thing that goes in the general statements section. "This horse is not from an area currently affected by VS" and that sort of thing. So, I concur with the attribute/value solution.

ssantamaria commented 10 years ago

Is this a suggestion to use a standard list for the diseases and standard values, such as (I'm making up the attribute names here for simplicity):

object= state (from list of state or herd) name= Brucellosis (from disease list) value=free (from status list)

If so, I like this approach better than enumerating all the possibilities in one list (state is Brucellosis free, herd is Brucellosis free, etc.)

mkm1879 commented 10 years ago

That is the way I read Michael's suggestion. I'm not sure he was thinking to enumerate the choices. If so, they would have to be the "coded with exceptions allowed" type of enumeration in case a state needs to assert that it is free of nose and tail disease once rules are in place for that.

sahola commented 10 years ago

Value: Free MA - Modified Accredited MAA - Modified Advanced Accredited

sahola commented 10 years ago

name: Brucellosis (state) Brucellosis (herd) Tuberculosis

mmcgrath commented 10 years ago

Will implement this following discussion on 10/7 -- I will make it a "values+other" implementation

mmcgrath commented 10 years ago

I will close this at the end of October unless there are objections before then

jconlon commented 10 years ago

See that ProgramStatusType was added to the schema, but it was added as a sibling element to eCVI element as:

I also see it referenced by: I don't think this is right, shouldn't ProgramStatusType just be a ComplexType?
jconlon commented 10 years ago

Sorry previous comment dropped my xml. Second line should read:

I also see it referenced by: the complexType PremType

mkm1879 commented 10 years ago

This is technically correct either way, but I agree with John that the pattern we follow through most of the schema is to define a complex type and then define the element with type="" Here we define the element and then define is use with ref=" It would seem to be better to stay with one or the other unless there is a good reason to do the other.

mmcgrath commented 10 years ago

I agree that consistency is a good idea in this regard -- @jconlon can you make your suggested change and push the revision referencing this issue in the comment please.

mkm1879 commented 10 years ago

Done. Note: The element name changes from ProgramStatusType to ProgramStatus consistent with the other fields.

I also fiddled with a couple of meaningless order of the maxOccurs= etc to be name, type, limits. I'll check that kind of thing throughout when I do the consistency check end-to-end.

mmcgrath commented 10 years ago

OK thanks for the speedy response @mkm1879 -- I'll leave this issue open for further comment and will close it on 13 December unless anyone objects beforehand.