Gregory Woodhouse wrote: >I've never worked with M2Web, so maybe I'm mistaken here, but I thought >its primary function was to generate XML documents from Fileman and >make it available via HTTP (not a small accomplishment). Am I mistaken?
Not mistaken in that generating and serving XML documents from Fileman or other MUMPS data is one of the capabilities, but that is far from its primary function at this time. The general functionality is that of a framework for developing and serving MUMPS applications and data to the web, hence MUMPS-to-Web, M-to-Web, M2Web. Potentially, any kind of data could be sent or received. Currently (in VMACS), the most used and useful data formats sent are HTML, Javascript, CSS, JPEG, GIF, PNG, WAV, AU, and a little XML. The server automatically decodes most data that is received as urlencoded or multipart/form-data and parses it into named values. Pretty much any type of data can be received as multipart/form-data. We use it for uploading clinical images with descriptive data, among other things. Applications can handle the parsing of alternate encodings themselves as needed. We expect to add a general parser for XML encoding one of these days, but we haven't felt much of a need for it yet since other available encodings have been easier to work with and more efficient for our uses so far. >Implementing CCR would also require the reverse: receiving XML >documents and save the parsed data as Fileman records. I've done this >in various special cases, but have not yet tackled the general case. Yes. Starting with special cases as needed seems to me to be the only practical way to go when working with limited resources. What sort of data are you sending and receiving with XML encoding and why use XML? Are the routines in OpenVistA? Do you see any value in using HTTP for the transport? >For HL7 messages, my approach is to create a FSM to drive the parsing >process and build an FDA array from the document. What is an FSM? Finite State Machine? > >==== >Gregory Woodhouse >[EMAIL PROTECTED] >On Apr 30, 2005, at 6:25 PM, Jim Self wrote: > >> I think you define web services too narrowly by confining them to a >> single document >> format. It seems to me that that ignores most of the capabilities of >> web servers and of >> their most ubiquitous and generally capable clients. I do see great >> potential value in >> providing application oriented services on the web and in using XML as >> a document format >> for that purpose. >> >> CCR sounds like a great project and one that could be easily supported >> by M2Web once a >> mapping of CCR tags and attributes to VistA data elements is defined. >> M2Web already >> provides XML output of VistA data on demand, but that capability >> hasn't been exercised >> very much yet - that I know of - because I and those I work with don't >> yet have a need or >> convenient opportunity to connect to anything that would benefit from >> it. >> >> A nameless entity "[EMAIL PROTECTED]" wrote: >>> Web services allow different applications from different sources to >>> communicate with each >>> other without time-consuming custom coding, and because all >>> communication is >>> in XML, Web >>> services are not tied to any one operating system or programming >>> language. >>> For example, >>> Java can talk with Perl, Windows applications can talk with UNIX >>> applications. Web services >>> do not require the use of browsers or HTML. >>> >>> It would be great if VistA supported CCR (Continuity of Care Record) >>> in some >>> shape or form through Web Services... >>> >>> CCR: >>> http://www.massmed.org/Content/ContentGroups/SectionsTopics/ >>> PhysicianPracticeResourceCenter/PPRCInformationTechnology/ >>> Continuity_of_Care_Record_FAQs.htm >> >> --------------------------------------- >> Jim Self >> Systems Architect, Lead Developer >> VMTH Computer Services, UC Davis >> (http://www.vmth.ucdavis.edu/us/jaself) >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: NEC IT Guy Games. >> Get your fingers limbered up and give it your best shot. 4 great >> events, 4 >> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >> _______________________________________________ >> Hardhats-members mailing list >> Hardhats-members@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/hardhats-members >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. >Get your fingers limbered up and give it your best shot. 4 great events, 4 >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >_______________________________________________ >Hardhats-members mailing list >Hardhats-members@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/hardhats-members > --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
