From: paulm@netzone.com (Paul McCumber) Newsgroups: comp.text.sgml Subject: Compiling SP with VC++ 4.0 Date: Thu, 22 Feb 1996 19:01:27 MST Organization: Netzone Message-ID: \ Summary: I can't get SP to compile with VC++ Keywords: SP VC++ I can't get SP to compile with VC++ 4.0. The makefile that is supposed to work with VC++ 2.1 doesn't work. I'll need to make changes. I've track down a handful but am afraid it will be much longer before I get it to work. I must be doing something wrong ... Has anyone got this thing to compile? What did you do? paulm@netzone.com From: Eric McCandless \ Newsgroups: comp.text.sgml Subject: Re: IETM - interactive SGML browsers Date: 23 Feb 1996 07:35:54 GMT Organization: NAVMAT Message-ID: <4gjqoq$1l8@navmat.navy.gov.au> References: <4gf3m5$noh$1@mhadg.production.compuserve.com> Try this excellent US Navy site http://navysgml.dt.navy.mil/classes.html From: jonsm@aol.com (Jonsm) Newsgroups: comp.text.sgml Subject: more HTML DTD and RE Date: 23 Feb 1996 02:26:10 -0500 Organization: America Online, Inc. (1-800-827-6364) Sender: root@newsbf02.news.aol.com Message-ID: <4gjq6i$rba@newsbf02.news.aol.com> Reply-To: jonsm@aol.com (Jonsm) More on HTML and RE processing... Here's a repeat of the example I'm working with: \ \foo\ \ \
\
\0
\1
\3
\
\
\ The snippet of code from yasp that is causing me the problem: from stower.c: if (rct == INCLUS_MS) { ded_is |= PEX_LF; tcb_p->is.b.pex = TRUE; FG_OTHER(M_p); *++M_p->state_p = STG_STATE; }else { /* tcb_p->is.b.pex = FALSE; (already OFF) */ FG_STG(M_p); if (rct == REQRD_MS) { /* if omitted, */ ded_is |= IMP_LF; /* tell it's implied */ tcb_p->is.b.bad_empty = TRUE; /* must check empty */ } } After encountering the first 0 in the example, state_p is set to 3. The input tag is an inclusion in the HTML DTD so we go into the first half of the if. FG_OTHER sets the state to 4 which delays the TELL for RE until after the inclusion (INPUT) is processed. Is this what SGML is supposed to do or is this a bug in YASP? Non- inclusion elements do not have this problem. Jon Smirl, jonsm@aol.com Newsgroups: comp.text.sgml From: lee@sq.com (Liam R. E. Quin) Subject: Re: What are the limits of marked section declarations? Message-ID: <1996Feb23.000812.27598@sq.com> Organization: SoftQuad Inc., Toronto, Canada References: <4fg9pb$11h@news.cerf.net> <4fni9l$imh@cliffy.lfwc.lockheed.com> Date: Fri, 23 Feb 1996 00:08:12 GMT Tad McClellan \ wrote: [...] >These are primarily implemented with the \, \, >\ and \ elements. > >e.g. [...] > \ > \NUM_SEATS\ > \ > \1\ >\ is a variable name that the SGML application has set >previously (as initialization, or by another IETM document). > >The SGML app evaluates the \ and if TRUE presents the \ > else skips \ > >Kinda ugly, but workable... Actually I am beginning to think it is not so ugly. A set of architectural forms could be defined (have been defined, of course for the IETMs in your example) for a marked-section-equivalent for documents. Unfortunately (1) they can't work in DTDs, because the DTD doesn't use SGML :-( (2) they are restricted to being synchronous, which I actually think is OK. But suppose an app. is changed to deal with interpreting \ \ \ \ \ \\ \ stuff \ other stuff \ This is often requested for HTML, for example. Well, it could also have other changes. As long as you have a mapping between good old ugly SGML :-), you're OK. But that mapping has to be sacrosanct, so that older documents can still be read in 100 years' time, the single most important promise (I claim) of SGML. So then you could do \ \Age of Applicant\ \appl.age\ \ \ \numeric\ \ \ \ instead of \ \ \ (or using HyLex) In general, I prefer using a single syntax. You don't actually need all these syntactic forms that interact with each other. Attributes can be modelled as elements just as efficiently. One difficulty is that there's no scoping -- I'd like to be able to say something like (I'll revert to DTD syntax for familiarity): \ \ to specify that a \

element has different content in different places. But what I'd end up with after all this wouldn't be SGML any more. Perhaps the best thing about SGML is that it's SGML, a standard. Lee -- Liam Quin, SoftQuad Inc +1 416 239 4801 lee@sq.com HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval \ SoftQuad Panorama, HoTMetaL, Services, SGML tools `The future holds promise for those who have faith in it' [Inglis billboard] From: James Clark \ Newsgroups: comp.text.sgml Subject: Compiling SP with VC++ 4.0 Date: Fri, 23 Feb 1996 10:01:48 +0000 Message-ID: <9602231001.AA20231@jclark.com> References: \ In-Reply-To: paulm@netzone.com's message of Thu, 22 Feb 1996 19:01:27 MST > From: paulm@netzone.com (Paul McCumber) > Newsgroups: comp.text.sgml > Date: Thu, 22 Feb 1996 19:01:27 MST > > I can't get SP to compile with VC++ 4.0. The makefile that is supposed to > work with VC++ 2.1 doesn't work. I'll need to make changes. I've track > down a handful but am afraid it will be much longer before I get it to work. > > I must be doing something wrong ... In most cases to port SP to a new compiler you need only change lib/config.h. I haven't installed VC++ 4.0 yet, but I'm told the following works: *** lib/config.h.~8~ Fri May 12 12:31:33 1995 --- lib/config.h Sun Oct 29 11:11:28 1995 *************** *** 35,41 **** #define MSDOS_FILENAMES #endif ! #if _MSC_VER == 900 // Microsoft Visual C++ 2.0 #undef INCLUDE_UNISTD_H #define INCLUDE_IO_H --- 35,41 ---- #define MSDOS_FILENAMES #endif ! #if _MSC_VER >= 900 // Microsoft Visual C++ 2.0 #undef INCLUDE_UNISTD_H #define INCLUDE_IO_H *************** *** 55,61 **** --- 55,63 ---- #pragma warning ( disable : 4018 ) // signed/unsigned mismatch #pragma pointers_to_members ( full_generality, single_inheritance ) #define huge verybig + #if _MSC_VER == 900 #define DECLARE_PLACEMENT_OPERATOR_NEW + #endif #define set_new_handler _set_new_handler // Function passed to set_new_handler() returns int and takes size_t argument. #define FANCY_NEW_HANDLER James Clark jjc@jclark.com From: jonsm@aol.com (Jonsm) Newsgroups: comp.text.sgml Subject: RE and HTML DTD Date: 22 Feb 1996 21:30:29 -0500 Organization: America Online, Inc. (1-800-827-6364) Sender: root@newsbf02.news.aol.com Message-ID: <4gj8s5$l5n@newsbf02.news.aol.com> Reply-To: jonsm@aol.com (Jonsm) I'm having trouble with RE indication and the HTML DTD. Here's the sample text I'm trying to parse: \ \foo\ \ \

\one \two \three \
\ YASP is indicating the RE's after the \ tags instead of at the obvious EOL. If I change the example to: \ \foo\ \ \
\one \two \three \
\ The RE are indicated in the proper places. In the HTML DTD INPUT is an inclusion item in the FORM element. Switching INPUT to the content of the FORM tags also makes the problem go away but can't be done since it causes other problems. from DTD: \ alternative: \ Does anyone have any idea what is going on? I've been tracing around inside YASP and I find SGML EOL processing to be very complicated. Could this be a bug in YASP or is the part of the wierd SGML EOL processing rules? Jon Smirl, jonsm@aol.com Newsgroups: comp.text.sgml Date: Fri, 23 Feb 1996 11:05:08 -0600 Message-ID: <9602231705.AA23105@fly.HiWAAY.net> From: Len Bullard \ Subject: Re: DTD for *incorrect* HTML [Eliot Kimber] >But frames aren't hyperlinks in the HyTime sense (of defining a typed >relationship between anchors)--they simply address their content in a way >that is analogous to the content location (conloc) feature of HyTime. >It's important to remember that not all uses of location addressing are >hyperlinks. Yes. I understand. I viewed them that way because I interpreted them as resembling the MID get link which is based on an ilink and which fetches the target. But your comparison is correct. The semantic of the frame is *Get This and Render Here* and points to the target file as well as containing properties that describe the relationship of the local space to the world coordinate system. A link with a target says says Get This And Render There. However, since I seem to be confusing the issues, perhaps you could refresh me on how links and locations are different. I think I understand this, but for the sake of this discussion, it might be best to see if we have precisely the same idea. It might also help any lurkers who wonder just what the heck we are discussing. ;-) >Actually no. The indirection itself should be trivial to process and have >no noticable affect on performance (assuming that the extent specification >and the event are in the same document and not too widely separated). >It's the overhead of interpreting the extent specification itself that >might effect performance depending on what you allow. If you only allowed >simple dimension specifications, it wouldn't be bad at all, but if you >supported marker queries or dimension references, it could get a bit >involved. OK. Thanks for straightening me out on that one. It seems to me though, that separation has some real problems. Take for example, a system that is trying to optimize display speed. If one uses forward pointers, that is, the links point to locations unresolved because the parser hasn't reached that part of the instance, then these must be reprocessed when the parser does reach them. If it has to reload that structure back in some form to evalutate it, then some overhead is being invoked. PDF, for example, puts all of the connections in a structure at the end of the instance, and then, perhaps, parses bottom up? I don't really know. This isn't my field, but since the major complaint about HyTime seems to be "can't be optimized for runtime", I am interested in shaking these issues out. Perhaps someone with more expertise than I in parsing SGML and loading structures into memory can comment. >However, it's difficult to imagine that in the case of a frame-type >application that it would, for example, take longer to calculate geometry >specified as HyTime dimension specifications than it would to download and >run a java script. (Of course, I suppose you could write a java script to >interpret HyTime event schedules, for that matter....) Interesting idea. As Java is in essence, C++, it is probable that it would work. I am unsure what the advantage would be in the single case of presenting windows. Java has its own library, and I assume, its own method of specifying world and window coordinate systems. OTH, follow that argument far enough, and a Java user doesn't need HTML really, as they can specify their own syntax and use the plug-in features to display it. It gets a bit more interesting if the plug-in format, e.g., VRML enables the use of sub-notation calls, that is, the display of HTML inside VRML inside HTML inside Java inside the Netscape framework. >The whole issue of work flow and how workflows might be represented in a >general way, specifically with SGML and/or HyTime, is a very interesting >one. Unfortunately, we are in the process of trying to do just that for >our PassagePRO product, so I can't really discuss my ideas on the subject, >as much as I would like to. It is understood. Sounds exciting. Tell us more when you can. >But in the case of the paper presented at Hytime '95, I didn't entirely >agree with their approach. I thought that one of the uses they had put >FCSes to (associating work flow nodes with "actors" by defining an "actor" >dimension) was an inappropriate use of FCSes because FCSes are a weak and >overly-complex way to represent lists of property values. In other words, >while an FCS may bear a nominal resemblance to a relational table, it is >not in fact, defining relations in the relational sense--that's what >hyperlinks and attributes do. Interesting. You and Steve Newcomb should take that one up because the relational aspects of FCS are precisely why the MID has them as its sole table spec. We did leave it in a tableTypes entity for folks who had other ideas. >My personal feeling is that most of what you need to do in situations like >modeling workflow or representing change over time (the subject of my >paper at Hytime '95) is best done with typed links and normal SGML >structuring and identification mechanisms. Arbitrary views of these >relationships might be structured and presented using FCSes, but the >properties of objects and the relationships among them are not *defined >by* FCSes. Yes, I can see how that would work. When I was working on the problem some years ago, I wanted to nest the FCS to represent the kind of process/control nesting one sees in real-time control system specifications. This enables the property of time to be abstract, as it is in music, and therefore, scaleable as it must be to represent Work Breakdown structures whose opening and closure are subject to the control values, e.g., process A requires nested A(sub1) to close before transition to A2. Events are the contents and each event would have both a time property and a set of task properties. It looks very fractal-like and there is where my eyes glaze over, because it is a non-linear system. In the infamous Appendix F of the IETM implementation guide, my contention was that the events on the axes were links because to me, that corresponded nicely to the dominant/subdominant axis approach. That is, one axis is primary and might represent, for example, an indentured address (e.g., 3.5.7) in a scaling system, and other axes would represent the linkends that could be members of other event schedules. I had an inkling that the sparse matrix produced was amenable to imaginary number algorithms for navigation and that a view was the result of obtaining that number as an intersection in the multi-dimensional coordinate system. To me, this looked intuitively like multi-dimensional database concepts such as are used in data warehousing. What I was after was a hypermedia system in which the organization within the hierarchy of the schema was sufficient to establish the relation membership, therefore, once one knew this, any target for pouring into a rendered view was automatic. As Erik Naggum cautions, quite rightly, feelings are not science. But intuition is sometimes the 2% of it that gives one a direction. >Printed musical notation is an example of a view of a set of objects with >a wide variety of properties presented through a coordinate space where >one axis happens to be used to indicate one of the property values of the >objects. The objects are notes. One axis places the notes in time >relative to other notes (in the same event schedule or in other, >synchronized event schedules, i.e., different voices in the same >composition), the other axis represents visually one key property of >notes: pitch. Notes have many other properties that are represented not >by placement along an axis but by other conventions (diacritical marks, >written instructions, other symbols, implication from musical style, style >of performance, etc.). Yes. This is the case. But it should be remembered that the notation is inexact and subject to the baton controller (guy with stick waving it in face of orchestra and grimacing) to set the scaling values as well. That is, unlike a computer clock for which time is discrete, time is represented discretely in music, but executed continuously and against a scaling value determined by the baton motion and the grimaces. In some ways, this is much more like the WBS system of FCS nesting in which the manager acts as a sensor to external events and reorganizes the tasks dynamically to ensure closure and to prevent pathological cascades. >Because in Western music notes nominally have a small number of discrete >pitch values (e.g., the notes on a piano keyboard), it is convenient to >represent them graphically along an axis. But clearly, you couldn't >represent all the other properties of notes graphically on axes either, as >you'd soon run out of easily-interpreted axes (depth could represent >volume, for example, but what about attack?). Yes. Also true for scheduling process/control systems. At some point, one starts seeing hyperbolic presentations. It becomes more convenient to represent the values of interest as objects in a 3D/4D space whose expansion, contraction, colors, shapes, positions, orientations, nearness to camera view, etc., become metaphorical visualizations of system behavior. This is, of course, how VRML can augment HTML by serving the syntax from a database which schedules and calculates real or near real-time values obtained from some environmental sensor. >Thus, in a generic encoding of music, you probably wouldn't define a >note's pitch by defining a two-dimensional coordinate space where one axis >represents pitch and then creating events where the extent of the event in >the pitch axis defines a note's pitch. Doesn't make sense. For one >thing, pitch can be much more efficiently represented as a single-valued >attribute: \ or \. I take as support for this >the design of the Standard Music Description Language, ISO/IEC 10743, >which uses a one-dimensional coordinate space to represent music. The one >axis is a time axis and all other properties of notes are either >attributes or "extended properties" (elements addressed from the main >object that perform the same semantic role as element attributes). Yes. In a sense, links as scheduled events? >This same argument applies, I believe, to the use of an axis to *define* >the "actor" property of nodes in a workflow. Rather, it probably makes >more sense to either have actor be a direct property of workflow node >objects or to use a hyperlink (Is Actor) to relate workflow node objects >to actor objects. Yes. >Or said another way: relational tables are simply a convenient way to >represent two-anchor hyperlinks that don't require a lot of additional >data structuring. The fact that we visualize these tables as matrices >does not, in and of itself, mean that event schedules and finite >coordinate spaces are a useful way to encode these same relationships. A relational system is, in effect, an indexing convention. So are hyperlinks with locations. The relational system requires a JOIN/VIEW operation to do what we might do with strongly-typed links and location models. So, I am back to the formula from HyTime94 for dynamic linking to create views. Very good analysis, Eliot. You are the expert! Len From: Arjan Loeffen \ Newsgroups: comp.text.sgml Subject: comp.text.sgml shadow archive Date: 23 Feb 1996 14:48:45 GMT Organization: Computer & Humanities, Fac. of Arts Message-ID: <4gkk4d$f70@newshost.cc.ruu.nl> Dear reader I have created a new comp.text.sgml shadow archive in HTML. This archive lets you browse around the submissions of the last 5.5 years. It isn't grand, but may be helpful when you have been looking desperately for some info that you think may have been treated in the comp.text.sgml discussion group. I must apologize for not updating the previous archive. The program files were lost in a system crash. Also, Erik has changed the archive's storage form in the meantime. I now hope to run the update program every month. And yes, I have a backup. The introduction is available at: http://www.let.ruu.nl/C+L/loeffen/archive/cts/intro.htm I hope to create a search engine for the submissions in the near future. Hope you may find this useful in some way, 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 ---------------------------------------------------------------------- From: boeing \ Newsgroups: comp.text.sgml Subject: HAS ANYONE EVER HEARD OF OR WORKED ON A DTP PACKAGE CALLED 3B2? Date: 23 Feb 1996 15:11:37 GMT Organization: Internet Africa Message-ID: <4gklf9$jaq@newnews.iafrica.com> 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 Newsgroups: comp.text.sgml Date: Fri, 23 Feb 1996 14:01:53 -0600 Message-ID: <9602232001.AA16299@fly.HiWAAY.net> From: Len Bullard \ Subject: MID Examples While we're all showing our IETM code examples, here's one from the MID project. I've annotated it to show some changes from MID I to MID II. This is an old example derived for two prototype MID players from 1994. In MID II (1995), an important addition was the relationship arch form that allowed us to add strongly-typed links in application profiles. There are examples of that in the MID Application Guide recently delivered to the US Navy with the MID II Reader prototype. This example was part of one used to show a profile of MID that corresponded to MIL-PRF-87268 style conventions in which a display usually has a single instruction in it. So while the ratio of content to markup looks bad here, that is a decision for the MID author to make. This is also a "hard" MID. The MID language was designed to make it easy to keep content in a database under its own schema (e.g. DTD) so that MIDs could be written against multiple DTDs and different notations. Here is a MID-1 infoContainer that put up a condition to evaluate and a goto link. MID II shrinks the syntax a bit, and some creative mapping could shrink it a bit more, but human readability was a goal and I wanted a DTD sensitive editor to do some CASE-like things. ;-) As commented, some bits have since been moved into attributes or removed where unnecessary. Durn near everything is minimized, in a MID instance, but I left some of the end tags in to make it easier to follow. \ \\Boolean \ \power \ \\Check power to house. \\\ \IS POWER TO HOUSE ON? \ \\ \