As one of the last members of the MUMPS Development Committee, I think back on the long deliberations and the masses of paper we all carried around. We met as many as 4 times a year, but that became 3 times a year as the load of proposals and advancing documents thickened and our busy time was consumed. At our peak we were more than 60 members divided into corporate implementors, contractors and consultants, and academics and end users. The collegiate nature of this effort had a number of stressors which advanced and retarded the process of pushing out the next standard.

Times have changed and we cannot afford to wait 14 years for the FILE command to be completed. The needs of the community are more immediate, To this end, there is a reference version of MUMPS being prepared which will be readily available to developers to try new functionality and implement new ideas not yet applied. To this end, we would like to have the new MDC more of a larger community with more eyes looking at these new capabilities and see and evaluate the pros and cons of these new ideas. This may take the form of RFCs (Requests For Comment) which has worked so well for IEEE in forming their proto-standards for new messaging and protocols. This would mean that the proposals would be given wider viewing and criticism can be made public for all to see and comment on. Given this design of employing an RFC-like document structure and library approach, is this something that the community would like to see?

The IEEE is a good model. You may also want to consider the IETF as a prototype, which uses an open process. As a starting point for the IETF process see http://www.ietf.org/about/standards-process.html . I envision something like a mumps-draft, with separate drafts describing specific extensions, such as $REFERENCE and SET $REFERENCE. As mumps-drafts move up the maturity and standardization ladders, they will eventually be incorporated in the newest MUMPS standard. This strategy also has the advantage of making the process of deciding what will be included in the standard an open process.

We are producing more than a reference version; we are producing the new MUMPS standard. The chair and vice-chair are exploring our options for the best way to achieve that status. At the moment, the vice-chair strongly leans toward ANSI and ISO for this next standard, for the authority and continuity we need to gracefully cross this twenty-year gap between MUMPS standards.

After the next standard is finished, we can once again consider our other options, but the vice-chair believes that a few changes to the MDC constitution and proposal rules will be sufficient to tune up the MDC's agility; IEEE and IETF played a role in inspiring those changes, as did empirical study of MDC's past performance. The chair and vice-chair have been exploring those changes, and will propose them to the MDC membership in due time.

At the moment, we are more concerned about doing the work required to create the next standard. Indeed, more working and less debating is one of the principles we brought to bear to the changes we will propose, by structuring the debates more productively. For now, though, I hope to draw people's attention more to the MDC Type A Extensions and the work involved in implementing and validating them.

I think I understand what you mean by "more working". There is a lot of debate on IETF lists, and in meetings. The working principle there is "rough consensus and running code", and it's not always easy to reach rough consensus. I'm sure that working toward a new revision of the ISO standard will impose additional constraints on the way the MDC works. (The goal is a new revision of ISO 11756, right?)

Yes, that is our target.

ANSI and ISO always liked the rigorous MDC processes, which is why MUMPS has long used the coveted ANSI fast-track process. So long as we follow our established processes, we should get the same treatment with our next MUMPS standard.

[quote="toad"]Yes, that is our target.

ANSI and ISO always liked the rigorous MDC processes, which is why MUMPS has long used the coveted ANSI fast-track process. So long as we follow our established processes, we should get the same treatment with our next MUMPS standard.[/quote]


I'm hoping that is true. A hiatus of over ten years sometimes means that things that used to be easy to do become much more complex.

David

After we get TG19 launched, the map published, the MDC Type As published, and our March meeting out of the way, I'll turn to ANSI, to start rebuilding our relationships there in preparation for the new standard.

Thanks for the great Info

MUMPS standard
I think it's time to develop a new MUMPS standard. There should be no eligibility. Much time has passed, the information world has changed a lot. There are new ideas. MUMPS has become an archaic language. InterSystem understood this and actually developed another language. Directions where you need to develop the language they chose correctly. But their implementation killed MUMPS. Such improvements are not acceptable, but this is a working MUMPS system. Programmers use it. It is necessary to develop a standard that will preserve the ideology of MUMPS and incorporate current trends and new ideas. I propose such a standard. I have already developed a working MSH interpreter. You can try it out. I can send it to the mail.

I agree that the M standard needs to be refreshed.

I know a few friends who have discussed this before.
I am thinking about putting a newsletter/summary of these discussions on mumpster.org
where would be a good place to put it on this website?