Talk:HTC Position document: MIF, Repositories & HL7 Work practices
Issues with section entitled "MIF"
- GWBeeler 19:26, 17 January 2007 (CST) --Start--
I revised this section with caution:
- I tried to NOT change Grahame/Laura's intent or order in the presention
- I found it much easier to deal with by adding a set of sub-headings making it clearer what was the goal of each set of paragraphs
- I tried to distinguish between tools-smiths and tool-users, as opposed to "internal HL7" and not. I believe I did not do damage to your intent.
- In a number of places, I reduced lengthy phrases but keeping the same meaning, and in others I removed redundant statements.
I hope you will not feel I have violated what you were trying to convey.
- GWBeeler 19:26, 17 January 2007 (CST) --End--
Woody 15:15, 11 December 2006 (CST) -START-
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
Post Conf Call <Woody 08:39, 14 December 2006 (CST)> I will address the first three three bullets above by adopting a phrase like HL7-specific format (to replace internal) and further define the requirements -- methodology constructus and constraints that go beyond what can be directly expressed in UML2 and, therefore, need a robust expression not available in things like XMI. AND address the fourth bullet by stating that MIF is intended for developing HL7 specifications and refining those specifications for implementation (implementation profiles, etc. </Woody>
- "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) -END-
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"
- GWBeeler 20:21, 17 January 2007 (CST) ---Start--
In making changes, I tried to do only what was listed below as "agreed upon" content.
- GWBeeler 20:21, 17 January 2007 (CST) --End--
- 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??
- 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)
- <Woody 09:20, 14 December 2006 (CST)> The key question here is at what is an "artifact"??? For example, today's MIF says that you have a MIF file for each static model, but not for each 'attribute' within that model, although arguably, that is an artifact. I truly believe we will drown in the sea of MIF files we are about to create unless we have a very robust method of managing those. A database can help me (as a user) deal with the fact that RX wants to define over a thousand application roles, but my file system shows these to me as a jumble. I have more than a little angst about MIF defining a file for each application role and trigger event rather than assembling these in dynamic model packages. But that is probably an issue for MIF2, not this document. </Woody>
- May I amend this section to exclude the latter reading??
- 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. --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.
- 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"
- agree with this lot of comments. I phrased it completely wrong --GrahameGrieve 04:30, 14 December 2006 (CST)
- <Woody 09:20, 14 December 2006 (CST)> Based on Con Call, I will amend this section to distinguish between "definitional" packages (everything within a 'domain') and 'Publishing' Packages (everything to be shown for that domain within this ballot) </Woody>
- 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!
- 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. --GrahameGrieve 04:30, 14 December 2006 (CST)
- <Woody 09:20, 14 December 2006 (CST)>In that case we are on the same page, and I will amend this section to clarify the intent.</Woody>
Woody 16:04, 11 December 2006 (CST)
Issue with section titled "HL7 Workflow"
- GWBeeler 20:33, 17 January 2007 (CST) ---Start---
Despite my vitriol below, I limited my changes to adding a sentence to the third paragraph that reduces, somewhat, the open-ended promises of the previous sentences.
- GWBeeler 20:33, 17 January 2007 (CST) ---End---
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)
Well, I don't believe any of those things, but I do stand by what I wrote. I don't think that what we wrote makes any of those claims.
We claim that if everyone can publish from the content, and if everyone knows what the problems are all the time, then the workload and tasks for this person will be much reduced. But we do not claim that the things above will go away.
Though "all subjects being balloted in HL7 will automatically fit into the MIF/methodology framework" is possibly something I have underestimated. --GrahameGrieve 04:34, 14 December 2006 (CST)
<WoodyB 09:29, 14 December 2006 (CST)>This is a spin and reality issue. HL7 contributors are high-energy, productive, and nonconformists. Today, every domain can desk-top publish their content for preview purposes, but MOST do not. They find the errors when they finally look at the ballot site and see their errors "in public". I agree with moving as much QA review into their hands as possible, and continue to try to do so for today's environment, but I do not feel that this will "free up" much resource at HQ. The past experience is that the increased complexity of each subsequent ballot just offsets the tool-productivity gains of the same cycle. (Fortunately :-) </WoodyB>