This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Talk:HTC Position document: MIF, Repositories & HL7 Work practices"

From HL7Wiki
Jump to navigation Jump to search
Line 22: Line 22:
 
#Second bullet item says "Each HL7 artifact should correspond to a single MIF document".  I am unsure how to read this.  On face, it is OK, each artifact is contained in One MIF document.  I am OK '''unless this means''' each MIF document will hold one artifact!.  In that case, particularly for Trigger Events, Application Roles and the like, we will have an explosive and hard-to-manage proliferation if itty-bitty MIF files.
 
#Second bullet item says "Each HL7 artifact should correspond to a single MIF document".  I am unsure how to read this.  On face, it is OK, each artifact is contained in One MIF document.  I am OK '''unless this means''' each MIF document will hold one artifact!.  In that case, particularly for Trigger Events, Application Roles and the like, we will have an explosive and hard-to-manage proliferation if itty-bitty MIF files.
 
##May I amend this section to exclude the latter reading??
 
##May I amend this section to exclude the latter reading??
 +
### no. Why not have many files. They are in the repository, so they manage themselves. Grouping them means that they get tied together in the work flow, which seems equally difficult to me. We could amend it to say that the application of this policy to itty bitty things is still under review --[[User:GrahameGrieve|GrahameGrieve]] 04:30, 14 December 2006 (CST)
 
#The third bullet, "The repository should store each MIF document as an individual unencrypted file in a fixed directory structure" seems in conflict with some of the Appendix requirements, specifically 3, 6, and 15
 
#The third bullet, "The repository should store each MIF document as an individual unencrypted file in a fixed directory structure" seems in conflict with some of the Appendix requirements, specifically 3, 6, and 15
 +
## Refer to the table in the appendix for discussion on this. --[[User:GrahameGrieve|GrahameGrieve]] 04:30, 14 December 2006 (CST)
 
#Fourth Bullet "Package-level artifacts would be documents containing header information only. Package contents would be inferred from artifact ids of other artifacts"  This is much too general.   
 
#Fourth Bullet "Package-level artifacts would be documents containing header information only. Package contents would be inferred from artifact ids of other artifacts"  This is much too general.   
 
##Assuming that a domain-publication is just another package, it '''must have''' more than header data.  This is where the domain-level justification, diagrams, etc. should reside.  Look at today's documents.  There are significant numbers of figures, tables, and structured descriptions at the domain level.
 
##Assuming that a domain-publication is just another package, it '''must have''' more than header data.  This is where the domain-level justification, diagrams, etc. should reside.  Look at today's documents.  There are significant numbers of figures, tables, and structured descriptions at the domain level.
 
##I presume that the package will also contain packages of references to included contents.  It is NOT possible, IMHO, to set every artifact to know ALL of the packages in which it may be published!!!!  Thus, it is not feasible to say "contents would be inferred from artifact ids of other artifacts"
 
##I presume that the package will also contain packages of references to included contents.  It is NOT possible, IMHO, to set every artifact to know ALL of the packages in which it may be published!!!!  Thus, it is not feasible to say "contents would be inferred from artifact ids of other artifacts"
 +
## agree with this lot of comments. I phrased it completely wrong
 
#Fifth bullet "The repository should make rules about the names and locations of the files within the directory structure, and validate the content" - If the repository cannot ALSO '''ENFORCE''' these rules, it is useless!
 
#Fifth bullet "The repository should make rules about the names and locations of the files within the directory structure, and validate the content" - If the repository cannot ALSO '''ENFORCE''' these rules, it is useless!
 +
## what does "enforce" mean?
 
#Final paragraph says we depend upon Gforge!!! Gforge has '''no native version control''' capability.  It can be used in conjunction with CVS or SCM, but do not say that Gforge provides versioning.  Or else, what I see in Gforge is badly explained.  For example, I cannot "release" a file that is in CVS without redundantly saving it to Gforge.
 
#Final paragraph says we depend upon Gforge!!! Gforge has '''no native version control''' capability.  It can be used in conjunction with CVS or SCM, but do not say that Gforge provides versioning.  Or else, what I see in Gforge is badly explained.  For example, I cannot "release" a file that is in CVS without redundantly saving it to Gforge.
 
+
## ?? not sure what the confusion is. I mean the CVS. I just called it the GForge cvs because it's associated with the GForge projects. the cvs is that master. --[[User:GrahameGrieve|GrahameGrieve]] 04:30, 14 December 2006 (CST)
 
[[User:Gwbeeler|Woody]] 16:04, 11 December 2006 (CST)
 
[[User:Gwbeeler|Woody]] 16:04, 11 December 2006 (CST)
  

Revision as of 10:30, 14 December 2006

Issues with section entitled "MIF"

I fear there is a grievous mis-match between my understanding of MIF, and what is documented in the section, entitled MIF. Specifically, it says:

  • "MIF is designed for internal HL7 use." -- NO, it was designed as the tool interchange format, REGARDLESS of whether those uses were "internal" to HL7, or used by an implementer. Otherwise, the NHS would have no use for MIF!!!
  • "MIF document should be opaque to all but the actual HL7 internal tool developers" - Again, wrong. It should be used by ALL who are developing tools and aides to facilitate HL7, regardless of whether or not they are "internal"
  • "The HL7 internal tool developers should provide tools and/or export facilities to other formats for all other uses of HL7 Model definitions" - Again - "internal developers" can never HOPE to finish this! We need OUTSIDE developers (like Eclipse) too.
  • "HL7 should position the MIF as an internal pre-publication format used to support HL7 development and publication processes" -- Again, it is NOT just prepublication. We have committed to asserting that the MIF-structured results are the NORMATIVE release of our specifications (in future.) And it is done to also support implementation
  • "HL7 should be committed to developing alternative standards-based approaches" -- This one is touchier, but the Tooling Committee long ago realized HL7 could not develop alternative standards-based approaches, but that we would encourage others (outside of, in collaboration with) HL7 to develop such approaches.

With your permission, I will edit the first two paragraphs and the final paragraph to "open up" the MIF beyond "internal developers".

Woody 15:15, 11 December 2006 (CST)

Permission will not be forthcoming from me. We could certainly more precisely define the meaning of "internal tools", since you are taking a narrower view of that than I intended. On the other hand, you are arguing for exactly the position that I want to position against. It's hurting HL7 when HL7 adopts it's own model interchange format and declares that this is how it is. If we can offer standard alternatives to MIF - and we can - why should we take the position that MIF is it? I'm not arguing for change of practice - note the position at the end of the section - I'm just trying to put a different spin on the position that is more standards friendly. --GrahameGrieve 04:21, 14 December 2006 (CST)

Questions/Issues with Section Titled "Artifact Repository"

  1. Second bullet item says "Each HL7 artifact should correspond to a single MIF document". I am unsure how to read this. On face, it is OK, each artifact is contained in One MIF document. I am OK unless this means each MIF document will hold one artifact!. In that case, particularly for Trigger Events, Application Roles and the like, we will have an explosive and hard-to-manage proliferation if itty-bitty MIF files.
    1. May I amend this section to exclude the latter reading??
      1. no. Why not have many files. They are in the repository, so they manage themselves. Grouping them means that they get tied together in the work flow, which seems equally difficult to me. We could amend it to say that the application of this policy to itty bitty things is still under review --GrahameGrieve 04:30, 14 December 2006 (CST)
  2. The third bullet, "The repository should store each MIF document as an individual unencrypted file in a fixed directory structure" seems in conflict with some of the Appendix requirements, specifically 3, 6, and 15
    1. Refer to the table in the appendix for discussion on this. --GrahameGrieve 04:30, 14 December 2006 (CST)
  3. Fourth Bullet "Package-level artifacts would be documents containing header information only. Package contents would be inferred from artifact ids of other artifacts" This is much too general.
    1. Assuming that a domain-publication is just another package, it must have more than header data. This is where the domain-level justification, diagrams, etc. should reside. Look at today's documents. There are significant numbers of figures, tables, and structured descriptions at the domain level.
    2. I presume that the package will also contain packages of references to included contents. It is NOT possible, IMHO, to set every artifact to know ALL of the packages in which it may be published!!!! Thus, it is not feasible to say "contents would be inferred from artifact ids of other artifacts"
    3. agree with this lot of comments. I phrased it completely wrong
  4. Fifth bullet "The repository should make rules about the names and locations of the files within the directory structure, and validate the content" - If the repository cannot ALSO ENFORCE these rules, it is useless!
    1. what does "enforce" mean?
  5. Final paragraph says we depend upon Gforge!!! Gforge has no native version control capability. It can be used in conjunction with CVS or SCM, but do not say that Gforge provides versioning. Or else, what I see in Gforge is badly explained. For example, I cannot "release" a file that is in CVS without redundantly saving it to Gforge.
    1.  ?? not sure what the confusion is. I mean the CVS. I just called it the GForge cvs because it's associated with the GForge projects. the cvs is that master. --GrahameGrieve 04:30, 14 December 2006 (CST)

Woody 16:04, 11 December 2006 (CST)

Issue with section titled "HL7 Workflow"

In re the third paragraph -- What are you smoking??

  • If you really believe that a complete ballot will come together by magic, with no "executive editor" to do validation, error checking, readiness assessment, completeness; and
  • If you really believe that our marvelous tools will never make a mistake such that we can always say "the editor/facilitator is wrong, the tools are right"; and
  • If you really believe that there will never be any ambiguities or alternate interpretations for the Methodology; and
  • If you really believe that all subjects being balloted in HL7 will automatically fit into the MIF/methodology framework,

THEN (AND ONLY THEN) will I ask Don Lloyd to step aside and make one of YOU RESPONSIBLE for getting the next two ballots out in time for a 30-day cycle just before a WGM.

Woody 16:04, 11 December 2006 (CST)