Received: from UICVM by UICVM (Mailer R2.03B) with BSMTP id 8479; Thu, 08 Mar 90 15:04:03 CST Received: from rutgers.edu by UICVM.uic.edu (IBM VM SMTP R1.2.1MX) with TCP; Thu, 08 Mar 90 15:03:58 CST Received: from texbell.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP id AA19530; Thu, 8 Mar 90 16:03:46 EST Received: by texbell.sbc.com (/\=-/\ Smail3.1) id ; Thu, 8 Mar 90 11:11 CST From: gary@txsil.lonestar.org (Gary Simons) X-Mailer: SCO System V Mail (version 3.2) To: u35395@uicvm.uic.edu Subject: AIW12 Cc: txsil!gary@texbell.swbt.com Date: Thu, 8 Mar 90 9:41:00 CST Message-Id: <9003081541.aa24624@txsil.lonestar.org> I hate to confess that I have only today really read your comments from January regarding my AIW12 work paper. At the time it arrived I glanced over it and chose to file it away so I could retrieve it and deal with all the comments at once. I thought that other members of the committee would respond, especially as they began working on their papers. Well, no one else responded (nor have I seen evidence of other work papers, besides the one from Italy). So my plan backfired. It is only now as I am preparing for the trip to Tuscon next week that I have unearthed your comments. I apologize for not getting back to you sooner. It is clear that you did give the paper a serious and thoughtful reading. I really wasn't trying to open up a debate over SGML in the first section, and I am quite happy to stand corrected in the areas where my inadequate understanding of the fine points of SGML resulted in my failure to do justice to what SGML can actually do. My intentions were very much in line with what you expressed when you said, "If we add our own formalisms for semantic specification we are simply working with SGML as it was designed to be worked with." I wasn't meaning to argue against SGML, but for the kinds of semantic specification we might want to add. At this point I'm not sure if there is any further use for that part of the paper so I am not immediately planning to try to polish it up. However, if we do decide it is worth refining, I will certainly take off the polemic edge you have reacted to. I only noted two points of clarification that would help in ensuring you understand what I was proposing. Both have to do with section 4.1 on general encoding rules. 1. You said it was not clear what happens when an attribute is defined as "instance of" a class, citing rule 1 and rule 3 as apparently contradictory. My intention is that both rules are true at the same time and thus that both markup tags occur. That is, as an attribute of the containing element, the <%attributeName> tag occurs. Then, because the attribute value is an instance of a class, the tag appears to open up the instance element. 2. This regards your question about global versus local naming: > Since you've defined a global name space for your class and value set > names I don't understand how different attribute names can represent > entirely different things depending on their immediate parent tag. That > is, I grasp the idea but can't see how it could be done in the formalism. I'm not exactly sure what you mean by "the formalism" in the last sentence. If you mean the formalism I have proposed, then I can answer. The idea is that the conceptual model could use the same attribute name for different element classes, but give them different type constraints in different classes. I don't see any conflict between that idea and the fact that class and value set names have a global name space. If, however, you meant "the formalism" to mean SGML, then you may have identified a serious problem with the proposal, namely, that SGML's requirement for a global name space would prevent the kind of application I am talking about (unless the attribute names used in the actual SGML markup were prefixed by the class name). Well, thanks again for the good comments. I trust I will se you in a few days at Tuscon.