From: Erik Naggum \ Newsgroups: comp.text.sgml Subject: Re: Can Entities be specific to certain Elements? Date: 26 Feb 1996 07:23:38 +0000 Organization: Naggum Software; +47 2295 0313 Message-ID: <19960226T072338Z@arcana.naggum.no> References: \ <19960222T055426Z@arcana.naggum.no> \ <312F3D64.1E5A@passage.com> \ <312FD3BC.425F@passage.com> \ <3130CFF0.3BA1@passage.com> [W. Eliot Kimber] | If you have invested millions or billions of dollars in the use of SGML | (or, like Singapore and Taiwan, significant aspects of your national | government's infrastructure), you don't want to see the standard being | changed hastily. this argument is entirely specious. ISO 8879:1986 is not going to change. documents conforming to it are self-identifying. ISO 8879:200X will also require self-identifying conforming documents. there is thus no chance of any loss of information or investments -- au contraire. for some hypothetical standard without a self-identifying declaration, your fears might have had some relevance. #\ -- the Internet made me do it From: pepper@falch.no (Steve Pepper) Newsgroups: comp.text.sgml Subject: Re: HAS ANYONE EVER HEARD OF OR WORKED ON A DTP PACKAGE CALLED 3B2? Date: Mon, 26 Feb 1996 09:53:06 LOCAL Organization: Falch Infotek AS, Norway Message-ID: \ References: <4gklf9$jaq@newnews.iafrica.com> In article <4gklf9$jaq@newnews.iafrica.com> boeing \ writes: >HELLO, I would appreciate any unfo about this package brought out by >Advent in England. I have been experiencing the most terrible problems >using it, and I am quite sure other users have the same hassles. We can >take it from there.Thanks for your time Adrienne, I cannot claim to have extensive knowledge of 3B2, but I have had the chance to look at it and play with it a little, and would be interested in hearing more about the problems you have encountered. [For those who have not heard of 3B2, it is a high-end typesetting system that has been around since the late 80s. It has a large share of the STM (scientific, technical and medical) typesetting market in Europe. I know of at least one large user who uses it for typesetting scientific journals encoded in SGML for publishers like Elsevier.] Since you posted your cri de coeur in this forum, I assume it is 3B2's "SGML support" that has been causing you trouble. This "support" was only added fairly recently and has a number of potential problems... 3B2 has always been able to handle SGML documents to a certain extent, because its native format is ASCII and because it uses the same delimiters as SGML for its internal markup (STAGO/TAGC and ERO/REFC for \ and \&references; respectively). This has meant that SGML documents that use the reference concrete syntax can be read into 3B2 and have typesetting instructions associated with the existing markup, without modifying the document in any way. What is new in the "SGML-aware" version, as I understand it, is the following: 1) The core software has been modified to allow tags with names that start with a slash, thereby making it possible to associate processing with end tags as well as start tags. 2) A mechanism has been added to allow an SGML declaration and a DTD to be associated with a document. 3) SGMLS is shipped with the product and may be invoked from within 3B2 for validation purposes. This is obviously a step in the direction of making 3B2 more suitable for typesetting SGML documents, but does not in any way constitute true SGML support. The core software still does not understand SGML. It does not parse the markup in accordance with the rules defined in 8879 and it doesn't "think" in terms of the element structure. This has a number of consequences. At the most immediate level, the application of style information is counter-intuitive for anyone who has worked with other products that allow formatting (however rudimentary) of SGML documents, whether it be editors like Author/Editor, composition systems like ADEPT or electronic delivery products like DynaText and Panorama. Styles are not associated with element types (qualified by hierarchy, occurrence, etc.). Instead the markup is entirely procedural: any state changes initiated by a start tag must be explictly revoked at the end tag, otherwise they will remain in effect. But far more serious -- and possibly the cause of the problems you are encountering -- is that parsing isn't in accordance with 8879. In SGML, two documents that are identical in terms of the information presented by the parser to the application, may differ widely in terms of the actual markup that they contain. This is true even in the case of two minimal SGML documents (i.e. documents that use the core concrete syntax, the reference capacity set and no features) if we take white space usage into consideration; for documents that use SHORTTAG, OMITTAG and short references, the differences can be very great indeed. What this means is that there is no guarantee that a 3B2 formatting application developed for a particular document type will always give the expected results, unless very strict markup conventions are developed and adhered to. Standard SGML conformance criteria are not enough. Other problems related to the lack of true SGML understanding, are that constructs such as marked sections, document type declarations with internal subsets and the like, are not even handled, much less handled correctly. Having said that, 3B2 _is_ a promising product, and it probably provides the most suitable solution for many traditional printers for typesetting SGML documents -- always provided that the user is aware of its limitations and is prepared to take the necessary precautions. In fact, 3B2 illustrates very well the need our community now has for a more precise terminology for describing levels of SGML support in software products. Today, more than ever, it is not enough to say "SGML aware" or "not SGML aware"... I would vote 3B2 half a unicorn[1] and strongly urge the developers to at least do what is necessary to achieve a whole unicorn. But enough from me. Tell us about your problems, Adrienne! Best regards, Steve [1] An oblique reference to the "SGML Purity Test" proposed by Charles Goldfarb at SGML '95 and since met by a deafening silence... -- Steve Pepper, SGML Architect pepper@falch.no Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ From: pepper@falch.no (Steve Pepper) Newsgroups: comp.text.sgml Subject: Backwards compatible SGML (Was: Can Entities be specific to certain Elements?) Date: Mon, 26 Feb 1996 11:29:28 LOCAL Organization: Falch Infotek AS, Norway Message-ID: \ References: \ <19960222T055426Z@arcana.naggum.no> \ <312F3D64.1E5A@passage.com> \ <312FD3BC.425F@passage.com> \ <3130CFF0.3B In article <19960226T072338Z@arcana.naggum.no> Erik Naggum \ writes: >[W. Eliot Kimber] >| If you have invested millions or billions of dollars in the use of SGML >| (or, like Singapore and Taiwan, significant aspects of your national >| government's infrastructure), you don't want to see the standard being >| changed hastily. >this argument is entirely specious. ISO 8879:1986 is not going to change. >documents conforming to it are self-identifying. ISO 8879:200X will also >require self-identifying conforming documents. there is thus no chance of >any loss of information or investments -- au contraire. >for some hypothetical standard without a self-identifying declaration, your >fears might have had some relevance. This is an extremely important discussion that I (for one) would like to see given an airing in this forum. As I understand it, one of the first principles to be agreed upon regarding the revision of SGML was that no changes should be introduced that would lead to a document that was conforming in terms of the old standard becoming non-conforming in terms of the revised standard. Now, I can understand the political arguments for this standpoint anno 1991 (at the time of the first periodical review). At that time, SGML was not mainstream; it had not established itself as THE solution for handling structured, "document-based" information; and it was far less widely understood than today. Any suggestion (at that time) that it might be changed in such a way as to render existing documents non-conforming could easily have scared off all those who were looking for a safe haven from the stormy world of proprietary, processing-oriented formats. And in any case, 1991 was still early days. We still didn't have enough experience to really know what would be the right direction to take. Of course, in a sense, we never will: To a certain extent we will always be feeling our way. All the same, my impression is that our understanding of structured documents in general and SGML in particular has "gelled" quite significantly during the last few years -- especially with the grand alignment of HyTime and DSSSL. So how important is the "backwards compatibility" principle today? Is it still so important that we should let it stand in the way of amending (or even redesigning) SGML along the lines of what we would have done if we'd known in the early '80s what we know today? And if backwards compatibility really is necessary, would it be a good idea to restrict it to certain classes of documents rather than have it apply to every single document out there? I personally have enough faith in SGML as currently defined to feel fairly confident that I will be able to transform any well-defined document into "revised SGML" without loss of information. I understand (and agree with) Eliot's point about not wanting to see the standard being changed hastily. Any steps that _are_ taken must be considered very carefully. But there can be no doubt that SGML contains a lot of historical debris. The computer scientists want a cleaner and even more powerful SGML. What do the users say? Best regards, Steve -- Steve Pepper, SGML Architect pepper@falch.no Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ From: ak@oasis.icl.co.uk (Alfie Kirkpatrick) Newsgroups: comp.unix.questions,comp.text.sgml Subject: Re: The horror of man pages Followup-To: comp.unix.questions,comp.text.sgml Date: 26 Feb 1996 08:25:10 GMT Organization: ICL, Bracknell, UK Message-ID: <4grqp6$9nl@ozz.oasis.icl.co.uk> References: \ <312B42C6.1B6E@gecm.com> <4gfpp8$d6@news.jhu.edu> \ <19960225T105324Z.hanche@chanur.imf.unit.no> <19960225T234641Z@arcana.naggum.no> Reply-To: ak@oasis.icl.co.uk Erik Naggum (erik@naggum.no) wrote: : back in 1992 (I think), the Committee for Common Man was initiated by Lar : Kaufman, I did some work for Unix Systems Laboratories to define a DTD for : man pages, converted a few hundred man pages to this format to test it, and : wrote several utilities, but CfCM never got off the ground, and USL decided : to go with the DOCBOOK DTD, which does not fill the need for man pages, for : political reasons. DocBook does have a \ tag which allows you to tag up manpages in a similar manner to troff. Novell did a lot of work converting the UnixWare manpages to DocBook and the results are pretty good. : to me, the perfect man page makes it possible to ask for the usage of a : command or function in a way that is immediately useful, without a lot of : clutter and noise. I have found that I need to know the order of arguments : to library functions more often than anything else when programming under : Unix. a simple "prototype lookup" would solve this. (I also need to know : which error conditions might occur, but that is very painful in C, anyway.) DocBook manpages have a \ element which may do for the prototype lookup you suggest. (I don't know the politics surrounding this...) Alfie. -- +-Professional Publishing Services---------------+ | Alfie Kirkpatrick ICL | | external: +44 1344 472500 Lovelace Road | | internal: 7263 2500 Bracknell, Berks | | mail: ak@oasis.icl.co.uk RG12 8SN | +------------------------------------------------+ From: gjh@ecs.soton.ac.uk (Gary Hill) Newsgroups: comp.text.sgml,alt.hypertext Subject: Re: Strongly-Typed Hyperlinks Date: 26 Feb 1996 11:37:26 GMT Organization: Electronics and Computer Science, University of Southampton Message-ID: <4gs61m$2ur@wapping.ecs.soton.ac.uk> References: <31164A18.25C4@passage.com> <4fvei0$fnr@Mercury.mcs.com> <4gf0qv$4v9@wapping.ecs.soton.ac.uk> <4ggfks$nup@gap.cco.caltech.edu> <4ghsps$bce@Mercury.mcs.com> In <4ghsps$bce@Mercury.mcs.com> jorn@MCS.COM (Jorn Barger) writes: >Gary: >>|> I'd also be interested to hear your reasoning for why one wouldn't want >>|> to link to definitions. We have an application which is used by first >>|> year biology students, which has an online dictionary, and that proved >>|> very popular with users. >If the dictionary is on the user's harddrive, this solves the latency >problem, but then the author loses control over what definition will >be offered. Ok, fair enough, I'd assumed you were arguing against them ona cognitive level. Latency is a problem I agree, but I'm not totally sold on the idea of abandoning ourselve to the assumption of a poor quality connection. In fact if presenting the new information in a separate window then a poor connection is more acceptable as one can continue reading the existing document, and with the example of definitions, the user is requesting additional info, but not to the exclusion of the current document, so they may well be happy to continue reading and check the definition once it appears. >Again, this might be nice, but one mustn't *assume* it's going to >prove itself better than every other authoring strategy. It's just >too easy to say "Linktype X popping up a subwindow solves the XX >problem", where the XX problem is really about ***optimizing literary >style***. If XX problem is about literary style then yes I _think_ I'd agree. In this case we're talking about separate windows for information that is supplementary to a document that is the current focus of attention. The problem is related to the cognitive overheads involved in jumping away to other information rather than literary structure (see details of Pat Wrights Hypertext 91 paper elsewhere in this thread). In this case the use of separate windows etc is directly addressing a particular problem. >And whether or not any browsers can pop up subwindows yet, hypertext >people still have to confront the lessons the WWWeb is teaching about >fitting style to the medium-as-it-stands, because these lessons will >still be relevant, even *after* the new features are added. Clearly one has to match the approach to the technology being used. My original point was that you seemed to be dismissing the use of links for definitions and footnotes as a general hypertext construct because they don't work on the WWW. Gary -- Gary Hill, Department of Electronics and Computer Science, University of Southampton, Highfield, Hants, SO17 1BJ, UK. Tel: + 44 1703 594490, Fax: + 44 1703 592865 From: sewell@as.tt.ba-ravensburg.de (Michael Sewell) Newsgroups: comp.text.sgml Subject: Need SGML FAQ Date: Mon, 26 Feb 1996 17:06:42 Organization: Berufsakademie Ravensburg Message-ID: \ If there is one can someone post me the SGML newsgroup FAQ, as I am just starting research in this direction. Thank you. Mike X:-)X email: sewell@tt.ba-ravensburg.de From: Raymond H. Stachowiak <74453.1747@CompuServe.COM> Newsgroups: comp.text.sgml Subject: Re: Backwards compatible SGML (Was: Can Entities be specific to certain Elements?) Date: 26 Feb 1996 14:57:14 GMT Organization: System Consulting Message-ID: <4gshoa$rqu$1@mhafc.production.compuserve.com> References: \ Life evolves, and so do standards. However, as mentioned in this thread, SGML ahs become mainstream. What this means is that there are hundreds of thousands of pages of material encoded based on the standard. This data was built using SGML because people want to neutrally endode data. Database system were developed based on and designed to use the features of the standard. We cannot simple chang ethe standard and now say we have old data that conforms to 1986 and new data that conforms to 200x. When we upgrade the standard we need to provide support in an upwardly compatible manner. Further we need to support all the features people use or provide an alternative that can be programmatically supported. I beleive everything evolves, but if the committee feels that as a group they have a free license to change the standard, then its not a standard, its a proprietary format that is susceptable to the whims of a committee. You cannot ignore the wealth of data which supports the existing structures. Ray Stachowiak From: Arjan Loeffen \ Newsgroups: comp.text.sgml Subject: HyTime lecture for comment Date: 26 Feb 1996 15:09:42 GMT Organization: Computer & Humanities, Fac. of Arts Message-ID: <4gsifm$f6e@newshost.cc.ruu.nl> Dear reader, I'd be happy to receive comments on a lecture that I will be giving for a workshop in Belgium. It's what I make of HyTime and can press into 40 min. My notes (not the sheets, that are much shorter, of course), are at http:///www.let.ruu.nl/C+L/loeffen/lecture/belux.psz (compr. postscript). If there's anything in there you may want to use, feel free. Thanks in advance. Arjan. ---------------------------------------------------------------------- Arjan Loeffen Achter de Dom 22-24 ++31+30536417 voice work Faculty of Arts 3512JP Utrecht ++31+206656463 voice home University of Utrecht The Netherlands ++31+30539221 fax work ---------------------------------------------------------------------- Newsgroups: comp.text.sgml From: lisa@gordian.com (Lisa Leone) Subject: The Future of SGML? Message-ID: \ Sender: lisa@chimaera.gordian.com. Organization: Gordian Date: Mon, 26 Feb 1996 20:01:18 GMT I'm looking for serious comments from people who are currently authoring with SGML, as well as those researching and moving into SGML. The question is: what is the future of SGML for document development and management? Background: My company is moving into online documentation. Right now we're converting FrameMaker docs to HTML for Web and CD-ROM distribution. The long-range plans are to move into an SGML authoring environment. I say "long-range" because our clients are not convinced that SGML is the way to go. The problem becomes more complex when you take into consideration that we would likely have to start learning SGML before the actual transition. I've heard general opinions from both sides: either SGML will continue to be an important standard and possibly the one to which most documentation will eventally migrate, or SGML will soon be replaced by something easier/better. What do you think, and why? Is there research on the subject that someone can point me to? Any insights and/or opinions are appreciated, even the devil's advocate approach. Please respond via email; I will post a summary if there is significant interest. Thanks in advance, Lisa ................................................................ lisa@gordian.com Gordian, 20361 Irvine Ave, Santa Ana Heights, CA 92707 ph 714.850.0205 fax 714.850.0533 "Do you think death could possibly be a boat?" -- Rosencrantz (Rosencrantz and Guildenstern are Dead) From: 102262.476@compuserve.com (Volker Wend) Newsgroups: comp.text.sgml Subject: Re: Compiling SP using VC++ 4.0 Date: Mon, 26 Feb 1996 18:07:40 GMT Organization: CompuServe Incorporated Message-ID: <4gsssj$oqd@dub-news-svc-6.compuserve.com> References: \ <4gkj8t$22a@maroon.tc.umn.edu> milor001@maroon.tc.umn.edu (R A Milowski) wrote: >In article \, >Paul McCumber \ wrote: >>I am attempting to build SP using Microsoft Visual C++ 4.0. >> [snip] >> >>Can anyone help me with either the immediate problem or better yet, has anyone >>got this thing to compile on VC++ 4.0? What did you do? >I have compiled SP with both VC++ 2.2 and VC++ 4.0 with much of a >problem. The only problem is that VC++ 2.2 and 4.0 do not allow you to >export templates. You must use a tool that extracts symbols from >object code (like DLLXPT32) and build a def file. I have not successfully >done this yet--but I know the POET people have (its a time thing for me). >Thus, you must use SP as a library right now instead of a DLL. Yes, I have a SP version as a DLL. As soon as I find somewhere a place where I could put my project file and some patches on the net I could distribute it. Perhaps James could integrate some changes back in his source code. Volker Wend From: "W. Eliot Kimber" \ Newsgroups: comp.text.sgml Subject: Re: Can Entities be specific to certain Elements? Date: Mon, 26 Feb 1996 11:03:59 -0900 Organization: Passage Systems Inc. Message-ID: <3132122F.583C@passage.com> References: \ <19960222T055426Z@arcana.naggum.no> \ <312F3D64.1E5A@passage.com> \ <312FD3BC.425F@passage.com> \ \ Truly Donovan wrote: ... > >SGML standard is simply too big and too entrenched to be changed without > >careful consideration and testing of proposals. If you have invested millions > >or billions of dollars in the use of SGML (or, like Singapore and Taiwan, > >significant aspects of your national government's infrastructure), you don't > >want to see the standard being changed hastily. > > I don't think I ever suggested that any of this should be done hastily or > should imperil the validity or life expectancy of existing correct documents > and/or application processing programs. On the other hand, I don't think it > is unreasonable to inquire every half decade or so as to whether anything is > happening. . . . I didn't mean to imply that *you personally* wanted a fast change--I should have said "one" instead of "you". Your inquiry is quite timely and appropriate. I mostly wanted to make it clear to watchers of this thread not to expect changes as quickly as they might have come to expect from other standards processes. I know you know that these things take time. [For those of you scoring at home, Truly and I worked together at IBM--I had the benefit of almost ten years of Truly's wisdom with regard to generalized markup and credit her both with showing me the power of generalized markup and challenging me to make my designs as solid as they could be (not mention teaching me to pick my fights carefully, but that's another story...). Truly was the main designer of the BookMaster (nee ISIL) GML language, from which IBMIDDoc is evolved. It is probably not a stretch to suggest that, after Charles Goldfarb, Truly knows as much about the politics and realities of data language standardization as anyone.] > At this particular moment, I'm not trying to solve any particular problem -- I > asked the question because the topic is one that has concerned me for a number > of years. The limitation on IDs, for instance, simply flies in the face of > the notion of reusability -- you can reuse this in the same document as long > as it doesn't have an ID in it. Yes, I know you can build specific solutions > to this, but you have to anticipate the requirement each time or else build > your own generic process and bypass the SGML ID/IDREF capability entirely. > > As for entities, I've always had a problem taking it as an article of faith > that they should not be redefinable. I would like a straightforward > redefinition capability but I know better than to ask for that, so I'll ask > instead for something that I just might get, which is multiple name spaces > (or, as I tend to think of them, "variable pools," but I realize that is a > very old-fashioned term). This requirement has validity for a number of > applications, including reuse with different variable values on each use. > Again, you can build application-specific processes for this, as well, if you > can anticipate every author's need. > > Even something as simple as pulling together a document from materials from > different authors where no one controlled the use of IDs or entities from the > outset can present a problem that doesn't need to exist. > > As you well know, I come from a background where the equivalent of the > redefinition of entities was a commonplace, and the many uses to which that > capability was put cannot be ignored. I think that these specific requirements are well met by the use of subdocuments for re-usable document components, in conjunction with using LINK to manage the local (and dynamic) redefinition of entities as needed. I gave a poster on the subject at SGML '95 and have been lobbying both users and vendors to use these ideas. I hope to have an expanded version of my poster on the Web in a week or so. I know I got the attention of at least one major editor vendor at the show. Exoterica's support for concurrent parsing is a very big step as well. Lack of browser support can be solved by pre-processing documents to convert re-used subdocuments to general text entities by mangling IDs and addresses to combine the multiple name spaces into one (at least when the DTDs of the parent document and subdocuments are "parser compatible" (meaning that all the subdocs are valid with respect to the DTD of the parent document)). I think the SGML community has reached the point where the re-use issues Truly raises are finally so compelling that they can't be hand waved or band-aided[tm] with the sort of ad-hoc solutions Truly mentions. We need a solid, workable, general solution. I think that subdocuments hold the key to that solution within the constraints of 8879 as it exists today. I also think that a revised SGML can provide more powerful solutions. I will do what I can to help define such solutions. There are a lot of people giving a lot of thought to these issues just now, so I am confident that we will have both thoroughly thought through the problems and have a number of attractive solutions to work from. -- \

W. Eliot Kimber(kimber@passage.com) Sr SGML Consultant and HyTime Specialist Passage Systems, Inc., 2608 Pinewood Terr., Austin TX 78757 (512)339-1400 10596 N. Tantau Ave, Cupertino CA, 95014, (408) 366-0300 \

"Mr. Thought Policeman, I don't wanna do no wrong..." -- "1984 Blues", Austin Lounge Lizards (http://www.webcom.com/~yeolde/all/lllhome.html) Newsgroups: comp.text.sgml From: Cheryl Simpson \ Subject: Re: Help.... Softquad To: panorama-support Message-ID: <3132388F.5E14@sq.com> Sender: news@sq.com (News Administrator) Cc: cheryl@sq.com Organization: SoftQuad Inc. References: <312E51D6.1532@tdc.com> <312DE84E.62DB@sq.com> <312FD239.1E3F@tdc.com> Date: Mon, 26 Feb 1996 22:47:43 GMT Roy Domingo wrote: > Thank you very much for your reply. > I still have one question to ask, if it is fine with you. How can I > insert graphics(BMP,GIF,WMF) inside Panorama Pro. Or what is the fastest > and shortest way to apply it?. Once again thank you very much. Graphics can be inserted using \ \ \