From ralmonte@cs.uml.edu Tue Sep 13 12:52:41 2005 To: Bob Lechner cc: Jing Tan Subject: Re: Schema file To XML? cgeggis probably used metaschema.sch or its .msdata equiv.? XML is really useful to represent metadata, not to replace RDB. Replace Schema for XML is worthy if we will use the XML to represent the metadata of the model. Reasons: flexibility and extensability. If somebody wants to use BDE as his Diagram creator and feeds its result to his own tool, he doesn't have to learn another way to describe metadata. he can use one of the many free tools to parse the model and couple to his application. Following Java: "write one, use everywhere", independent of any language. Using XML as database model is something that is still under research and its application is justified for event message system that use XML as the message format. This is called Native XML Database (NXD) There are a lof of information about it. (e.g. free NXD --> eXist) A lot of information about XML and RDB, check.... http://www.rpbourret.com/xml ----------------------------------------------- Lechner wrote: > Thank you Jing for trying out gemxml. > > It appears that pkeys (IDs) and fkeys (IDREFs) are not present > in genxml's output. In fact, AA has only 2 of its fields. > And BB has wrongly the same 2 AA-fields. Not very promising. > > I'll have to check the previous tests and perhaps there are > later updates by CGeggis under $CASE. > > R Lechner > > > From jingyoko@hotmail.com Mon Sep 12 15:00:07 2005 > > From: "Jing Tan" > > To: lechner@cs.uml.edu > > Cc: jtan@cs.uml.edu > > Subject: Re: Schema file? To XML? > > Hi Prof. Lechner, > > > > I was able to build the chgen and complete the TP.sch and LP.sch file as > > well as perform forward-engineering TP.sch or LP.sch into source code pr_*.c > > and *.h. It's pretty straightforward, isn't it? > > > > However, regarding using XML instead of Schema, after reading your email, I > > felt they are much complicated than I original thought. > > > > As your point out, I've taken a look at the genxml of Chris Geggis, and > > execute his java code on mercury machine. Unfortunately, the result was not > > I expected. It neither converted msdat nor sch into XML file. Besides there > > is a better way to parse the file by Java API. > > > > However, what format the XML file should be, it may be need some challenge. > > > > Maybe you are right: > > > > [So far, I don't see an application that justifies converting a simple and > > very readable tabular form into non-readable non-editable XML? - RJL050909] > > > > But, I still think we should be able to find a way to do it. > > > > Thanks, > > -jt > > > > > > ----------------------------------------------------------------------------------------------------- > > students AA /*1 Table of student records */ > > { > > AAid students_id c8 1 /* primary key field */ > > fname fname c30 0 /* first name of student */ > > lname lname c30 0 /* last name of student */ > > age age i4 0 /* age*=year*2**16+month*2**8+dayOfMonth */ > > gpa gpa f4 0 /* grade-point avg (range [0.00 .. 4.00]) */ > > } > > > > roster BB /*1 Table associating students with courses */ > > { > > BBid roster_id c8 1 /* primary key field */ > > AAid student_id c8 1 /* foreign key field */ > > cnbr course_num c9 0 /* dd.cno.sec */ > > cname cname c30 0 /* name of course */ > > } > > > > rosterData.xml > > ----------------------------------------------------------------------------------------- > > > > > > > > > > > > > > ..... > > > > > > > > > > > > .... > > > > > > > > >From: Bob Lechner > > >To: jtan@airvananet.com (Jing Tan) > > >CC: 05f523,cchen,cgeggis, sfrye > > >Subject: Re: Schema file? To XML? > > >Date: Fri, 9 Sep 2005 18:41:38 -0400 (EDT) > > > > > >Re: Schema file to/from XML? > > > > > >[Robert Almonte is also interested in XML. I invite you and him > > >or others to share your further thoughts with me. > > >More comments below - R Lechner] > > > > > > > From jtan@airvananet.com Fri Sep 9 16:44:37 2005 > > > > Subject: Schema file? > > > > From: "Jing Tan" > > > > To: > > > > Hi Prof. Lechner, > > > > > > > > I'm reading several current existed schema files such as bde2TT_TA.sch, > > >t2s.sch, jpbatch.sch, t2b.sch at cvs repository. Although they are very > > >simple, I think the XML file is more readable and easier parsed especially > > >by the java Document Object Model (DOM) APIs. Is there anyone intends to > > >change the architecture. > > > > > > > > Thanks, > > > > -jt > > > > > > > > > >Reply From RJL: > > >Chris Geggis began a genxml project in OOAD and finished it > > >in $CASE/02f592. I later moved it to $CASE/gen/genxml. > > >Toay I linked it from $PH/genxml for easier browsing. > > >I also copied $CASE/gen/genxml/docs to $PH/genxmlDocs. > > > > > >[mercury.cs.uml.edu(119)> echo $PH $CASE > > >/usr/cs/fac1/lechner/public_html /usr/proj3/case] > > > > > > > > >Geggis wrote forward and backwaqrd translation programs > > >in Java. He handled only metadata (.sch or .msdat) translation. > > >E.g.: > > > ls $CASE/gen/genxml/src > > > gen2xml.java GetOpt.java Makefile xml2gen.java > > > > > >In my opinion an XML version of the schema is useless > > >except as a front-end to other XML-based tools, such as > > >database front ends or Java programs. > > > > > >I am really interested only in the next step: > > >Transforming data (.dat files) between chgen apps and XML. > > > > > >Any 05f523 project MUST satisfy these essential requirements: > > > > > >1. The translator should either interpret or generate code from > > >an arbitrary metadata defin. file (chgen-style or its XML version). > > > > > >2. The transformation should be two-way, like genxml of Geggis. > > > > > >3. Conversion of .sch fkeys to/from XML's IDREF data type. > > > > > >4. Handle both chgen fkey types: > > > M:1 child-to-parent (iskey = 1) > > > 1:1 sub-to-superclass (iskey = c) > > > > > >5. Use of bde/schema/94sbde_schema.msdat as a test case. > > > > > >Without IDREF, XML is ignoring the real semantics of > > >EERD/RDB/network schema, and the most significant advance > > >which they provide over XML's tree-structured file hierarchy: > > >the symmetry which associative entities provide for automatic > > >code generation to navigate any M to N relation in EITHER direction. > > > > > >My intuition tells me that code to perform such translation > > >must be table-driven from schema/.msdat file content. > > >Table-driven makes it a candidate for a chgen-based project. > > >Instead, existing XML tools for data conversion based on XML schema > > >may expedite such a project. Perhaps Geggis' genxml output > > >can provide the input to an XML-schema-based translator > > >[or translator-generator - RJL20100908] > > >WARNING: Whatever XML tree-structure you choose to represent as > > >an EERD network graph, you will have to pick a spanning tree > > >within the network. Since the spantree is NOT unique, > > >fkeys in the schema have another binary property: > > >which fkeys are IN the chosen span tree, and which are outside it. > > >(The former ones are replaced by physical nesting, > > >but the latter ones must be mapped into IDRef values.) > > > > > >Note that bde can draw both forward arrowheads AND backward > > >arrowtails. That is enough to distinguish ONE spantree within > > >a directed graph. I recommend that notation as a graphic notation > > >for indicating a span tree within an EER diagram. > > > > > > > > >Another interesting possibility is the automatic reduction of > > >one M to N relation with attributes (as shown on UML Class Diagrams) > > >into one Associative Entity and a pair of 1:M relations (without > > >attributes). XML-based schemas could be used for this, > > >but I noted above that an IDREF and a nested child-set become > > >a non-unique and assymetric representation of the M:N association > > >(thus losing its beautiful symmery and uniqueness:-( > > >I have a mistrust of such distortions - (the KISS Principle > > >means Keep It Simple, which IMHO is done by keeping it symmetric. > > > > > >Inspired by the KISS principle, you might think a > > >relational table is merely a repeating group of identically typed > > >relational tuples, and each tuple is represented simply > > >in XML as a list of simple item name,value pairs. So the conversion > > >of .dat files to tables becomes trivial (provided you support > > >fkkeys as IDREF types not just as ints or strings). > > > > > >I fully agree with this - and that's why I don't think XML > > >representation of pre-declared data tables is very interesting. > > >(Conversion of arbitrary-schema-defined data is smore interesting:-) > > >That's also why IDREF data elements are so important: Without them you > > >'throw out the baby along with the bathwater'. > > >