Hello Chris. I did get your .doc attachment, via Pine/view/save, I haven't downloaded it to a PC and viewed it yet. My 9/5 message Okayed your taking 91.592 - did you communicate with Jim Canning gradcoord yet? Then he has to OK the course add form and section add to registrar. The summary below is fine as requirements. I need a design spec that is language-independent plus a justification for hosting this database converter in Java not in C++ with chgen support.. I feel Java is correct at least for your prototype, because of Java/XML free tool support, but the plan should give details. Perhaps it already does. Bob Lechner From cgeggis@earthlink.net Thu Sep 19 06:39:12 2002 From: "Chris Geggis" To: "'Bob Lechner'" Subject: Did you get my Design/Requirements Doc? Date: Thu, 19 Sep 2002 04:39:46 -0400 Dr. Lechner, I just wanted to make sure that you received my Design/Requirements document. I haven't heard from you and I just wanted to make sure that you received it (sent 9/12/02 7:43 AM). Perhaps you don't read emails with attachments? I could try to reformat it in plain text if that is necessary. I saw your email about a few paragraphs for Dr. Canning right after I sent out the document. I've reworded the Introduction, Terms, and Functionality section so that it should be what Dr. Canning is looking for. Here it is: XML has become a popular, useful, worldwide standard for representing data. UMass Lowell has been representing data in schema files which can be processed using a tool called "chgen" to create header files and c files which in turn create useful functions capable of manipulating data in a data file. There is a need to bridge the gap between the chgen style of representing data and the XML style of representing data. This need will be addressed by a set of tools that will be done as a Directed Study (91.592.209) under the supervision of Dr. Lechner. Terms *.dat - a chgen data file *.sch - a chgen schema file *.xml - an xml data file *.xsl - an xml schema file (this seems to be the correct convention, but I'm not 100% certain. I will verify this as I move forward) Functionality The set of tools will be written in Java. [RJL: I hope this does not preclude making it a menu option in bde.] [Your specs do not identify the .sch file that specifies the format of the .dat-side format. Why not? This should support arbitrary .sch schema content subject to chgen rules. ] [My preferred alternate is to IMPORT two tables TT and TA (+ SV = schema version) which are equivalent to the .sch file. These tables can be prefixed to the .dat file and imported and translated first, to define the DB format for translating the .dat file content to XML.] A *.dat data file will be converted to a *.xml file using a command dat2xml. A *.sch schema file will be converted to a *.xsl file using a command sch2xsl. [see my remarks above - Tables SV/TT/TA should be prefixed to the .dat file instead.] A *.xml file will be converted to a *.dat file using a command xml2dat. [Including the tables SV/TT/A which precede and describe the others?] A *.xsl file will be converted to a *.sch file using a command xsl2sch. [How to distinguish the two subtypes of .xsl file (.sch or .dat?) The tools will be able translate back to their original type of file after a file has been translated. [Reverse-translation is Mandatory - even if it restricts the capability or generality. Please think thru the implications of my alternate- a self-describing .dat file with TT and TA defining the tables/structs in the remaining rows. This may simplify the problem by minimizing alternatives - and it may stimulate ideas on the real implications of self-describing .xml files.?] It will specifically not be required that this program produce the "exact" same file when translating back to the original type of file. For example: If a *.dat file is converted to a *.xml file and then back into a *.dat file there will be no guarantees that the *.xml file that was converted into a *.dat file looks exactly like the original *.dat file. There are too many problems that would be associated with achieving this much precision. For instance, how do you track white space? Comments will be preserved in translations. [You do NOT have to guarantee white-space preservation, because pr_util from chgen does not care. BUT you need to consider if the chgen constraint "internal whitespace is permitted ONLY in the last field or column" needs to be locked in concrete for the .xml files we support. I believe this criterion is critical for supporting general applications in the most cost-effective way (including the freedom to have any amount of whitespace as field SEPARATORS when importing tables with FIXED numbers of fields or columns).] [Bob Lechner] Thanks in advance, Chris Geggis chris@geggis.com Thank YOU, Chris. Sorry I didn't get back earlier - Too much to do fixing bde and starting up 02f522. Bob Lechner PS: Please contact Jim Canning ASAP re: 91.592.209 registration. Here is my 9/5 copy to you that OKayed this to him and Tom: ======================================== Subject: Re: 91.592: SWEng (Project course only called Directed Study :-) To: cgeggis@earthlink.net (Chris Geggis) Date: Thu, 5 Sep 2002 13:19:31 -0400 (EDT) Cc: lechner (Bob Lechner), tom (Tom Costello), canning (Jim Canning) Hi Chris. Please fill out a course add/drop form and leave it in OS313 for Costello or Canning to sign BEFORE next Wed if you can. My section number last year was 91.592.209 (NOT 201). CC of this email to them is my OK for you to take this course this semester, because it is your last for the MSCS degree. Good luck. You have picked a good topic. It must be bilateral and compatible with genv12 (sjaganat's new version with log/replay support), although that shouldn't make any difference. The metadata must also be translated to/from XML (specifically, tables TT and TA). A possible extension is to support gencpp, which has template-based container classes for parent-child relations. Bob Lechner