HDTenEightyP/NetNews huggingface dataset:
From: drmacro@ralvm13.VNET.IBM.COM
Date: Mon, 11 Jan 93 10:42:28 EST
Newsgroups: comp.text.sgml
Subject: Re: FrameBuilder
          HyTime Stuff
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1

In an earlier posting, I showed a HyTime example that
used nameloc to create a location chain ending in a dataloc
element that located character data in a non-SGML file.
I had though that HyTime required a nameloc element to
create a location ladder, but I apparently misread the standard
(that's what I get for creating appends early on Saturday
mornings).

Looking back over ISO 10744, I can't find anything that would
suggest I *can't* refer directly to a dataloc by its own
ID, allowing me to reduce my somewhat convoluted ContentRefSpec
element to no more than an application-specific instance
of the dataloc form (further simplified by allowing an
ENTITY= attribute directly on ContentRefSpec in place of
locsrc=):

<!ELEMENT ContentRefSpec - O (marklist*) >
<!ATTLIST ContentRefSpec
             HyTime         NAME   #FIXED     dataloc
             DataContainter ENTITY #REQUIRED  --replaces locsrc--
>

Note that the minimized markup from my earlier posting and
the markup for the above definition are the same:  ContentRefSpec
containing marklists defining the data positions within the data
entity.  I've just simplified the underlying system itself.

I might want to keep my original, more complex, definition
if I need the following:

o The need to refer to multiple dataloc elements in order to
  define an aggregate location.  This requires a nameloc in order
  to provide a single local ID for multiple targets.  This is the
  power of the indirection of nameloc.  Think of it as an amplifier,
  where each opportunity for indirection is an opportunity to
  specify more target anchors for the links.

o The desire to provide application-specific elements with
  ContentRefSpec.  For example, I like to require a description
  element in elements to make the elements self-documenting,
  e.g.:

  <ContentRefSpec><desc>Purpose of this link</>
    <marklist>...
  </ContentRefSpec>

o Complete separation of HyTime elements and application-specific
  elements.  Using this design principle removes the need to
  require HyTime support for support of your application if the
  functions HyTime provides are optional within your application.  It
  also makes the boundary between your application and HyTime
  very clear and precise.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709
From: robin@utafll.uta.edu (Robin Cover)
Newsgroups: comp.text.sgml
Subject: Re: FrameBuilder
Date: 10 Jan 93 17:14:34 GMT
	<1993Jan9.231359.22740@news.eng.convex.com>
Organization: UT Arlington

The description of FrameBuilder's "SGML support" by Peter Cash is a
major stunner, if it is accurate.  The Fall issue of <title>Frame
Focus</> had a lead article "Frame Joins Forces with Datalogics" which
said, among other things:

     FrameBuilder provides full, native support for Standard
     Generalized Markup Language (SGML), a widely adopted ISO
     standard for document interchange.

Nobody doubts that Datalogics does "real" SGML, I assume, but the
truth about (current, projected) FrameBuilder deserves to be
clarified immediately.

Assuming that Frame technical support personnel are tuned to this
channel: may we hear a direct and specific reply to the points
made in Peter Cash's recent posting?  If Frame tech support will
not reply, than can we hear from others who currrently have
FrameBuilder in hand, and who have studied the specifics of its
"SGML support."

I thought that "full, native support for SGML" would mean a true
SGML editor that would read any SGML DTD + document instance and
get right to work.

Robin Cover

-------------------------------------------------------------------------
Robin Cover              BITNET:   zrcc1001@smuvm1  ("one-zero-zero-one")
6634 Sarah Drive         Internet: robin@utafll.uta.edu  ("uta-ef-el-el")
Dallas, TX  75236  USA   Internet: zrcc1001@vm.cis.smu.edu
Tel: (1 214) 296-1783    Internet: robin@ling.uta.edu
FAX: (1 214) 709-2433    Internet: robin@txsil.sil.org
=========================================================================
From: wohler@vnet.ibm.com (Wayne L. Wohler)
Date: Mon, 11 Jan 93 16:38:20 MST
Newsgroups: comp.text.sgml
Subject: Re: FrameBuilder
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1
            <19930111.081057.248@almaden.ibm.com>

I agree with what Eliot and Eric have said about the need for an
abstraction of the SGML information using an interface definition
through an applications interface of some kind.  I tend to think of the
SGML parser/entity "interface" as an export/import cycle into and out of
the data storage.  This data storage is accessed through Eliot's Logical
Access Interface for applications that support it.  The SGML "interface"
is used by any other SGML application that cannot make use of the
logical access interface.

Why have a logical access interface?  Why not use the SGML data as the
data storage?  Efficiency is one reason.  Backward compatibility with
current product code is also another reason.  In my thinking, it also
does away with concerns for markup minimization and entity structures,
although it cannot lose ignored marked section information or comments
(I believe Eliot and I have a minor disagreement on this).  At one level
I think that the semantics which may be accessed across this interface
must be flexible, depending on the nature of the application and the
"wit" of the developers; I can see some real value to a standard here
that many different products may plug into.  In any case, this
abstraction need need not mean a loss of important semantics if the
underlying data storage has the semantics necessary to carry the
necessary SGML information.

What is the necessary SGML information?  There is one definition today,
that is ESIS.  It is defined as that information which the SGML standard
indicates must be available to the application, no more, no less.
Unfortunately, given this definition some information that even a basic
SGML application may need could not be included ... like the name of
SDATA external entities.  The DSSSL group is planning to support this
ESIS definition in its work.  We have asked for a few additions to the
ESIS set to support our requirements.  In addition, DSSSL also supports
what we are calling ESIS+ which contains all the information necessary
to recreate the SGML datastream, including ignored marked sections,
comments, tag specification strings, etc..

The model is that DSSSL systems and DSSSL applications on these systems
may choose one or the other to work with (with appropriately defined
behaviour for both cases).  Are there other public definitions of the
"necessary" SGML information?  Every SGML product intrinsically supports
some view of what is necessary or unnecessary based on the information
the application has access to.

Wayne L. Wohler                   Internet:  wohler@vnet.ibm.com
Dept G82/910M                     IBMMAIL:   USIB29WX@IBMMAIL
Publishing Solutions Development             Phone: 1-303-924-0470
IBM Corporation
Boulder, Colorado  80301-9191
From: Erik Naggum <SGML@ifi.uio.no>
Date: 07 Jan 1993 22:20:40 +0100
Subject: Re: SGML for data querying
Summary: The element structure is the _result_ of sequential processing.

[Eliot Kimber]
:
|   <digression>
|
|   The examples above, and most SGML applications in existence today,
|   process SGML documents sequentially from start to finish.  However,
|   SGML does not require sequential processing, and it can make just as
|   much sense to define applications that work with SGML documents
|   wholistically as a tree, rather than sequentially, at least in the
|   abstract.  In this processing model, access is via queries, rather than
|   sequential access by waiting for the element you want to flow by. ...

This is a good point, but an important distinction needs to be made (and
"at least in the abstract" needs to be stressed).

The SGML document consists of one or more _entities_, each a character
sequence, which represents a fragmented linearization of the element
structure.  This fragmented linearization needs to be parsed (and
reconstructed) before we can access the element structure.  The element
structure can fruitfully be regarded as the _product_ of the parser (cf.
ESIS), and the parser has to parse the document "from start to finish" to
be able to build this structure.

According to the standard, the only way you can possibly parse an SGML
document is sequentially (cf. 6.2 SGML Entities), and any access other than
sequential in a data stream is to entities in it (cf. SDIF).

This problem has been discussed before, in relation to what #CURRENT meant
as an attribute default value declaration.

In order to access elements in the element structure non-sequentially, you
have to build some sort of index into the entity structure, or store the
data returned from the sequential parsing process.  Since element contents
can span entities (one of SGML's significant strengths), the demand on
software that accesses the unparsed entity structure is high, compared to
storing a fully parsed SGML document in some form optimized for retrieval
by the application.  This task becomes daunting in the presence of frequent
short references, character entity references, and references to other
internal entities.

Several interesting problems follow from the constraints that this
represents.  (No, that's not the "understatement of the year" -- it's only
January 7th. ;-)

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
Newsgroups: comp.text.sgml
From: lab@gdstech.grumman.com (Larry Beck)
Subject: Re: FrameBuilder
Reply-To: lab@gdstech.UUCP (Larry Beck)
Organization: Grumman Data Systems-Woodbury
Date: Mon, 11 Jan 1993 15:07:36 GMT

In article <1993Jan11.031921.5873@news.eng.convex.com> cash@convex.com (Peter Cash) writes:
>In article <ROBIN.93Jan10111434@utafll.utafll.uta.edu> robin@utafll.uta.edu (Robin Cover) writes:
>>The description of FrameBuilder's "SGML support" by Peter Cash is a
>>major stunner, if it is accurate.  The Fall issue of <title>Frame
>>Focus</> had a lead article "Frame Joins Forces with Datalogics" which
>>said, among other things:
>>
>>     FrameBuilder provides full, native support for Standard
>>     Generalized Markup Language (SGML), a widely adopted ISO
>>     standard for document interchange.
>>
>>Nobody doubts that Datalogics does "real" SGML, I assume, but the
>>truth about (current, projected) FrameBuilder deserves to be
>>clarified immediately.
>
>>I thought that "full, native support for SGML" would mean a true
>>SGML editor that would read any SGML DTD + document instance and
>>get right to work.
>
    I thought that the new Datalogics WriterStation was going to bundled
    into the FrameBuilder package to give them SGML capability. 

          Larry Beck

Newsgroups: comp.text.sgml
From: bernd@iss.nus.sg (Bernd Nordhausen)
Subject: Re: SGML for data querying
Organization: Institute Of Systems Science, NUS
X-Newsreader: Tin 1.1 PL4
Date: Thu, 7 Jan 1993 02:16:16 GMT

drmacro@ralvm13.VNET.IBM.COM writes:
(Stuff deleted)

: >So... Are there any SGML programming toolkits available which allow
: >for this sort of thing?  Is the ARCSGML/JClark suitable in this way?
: >(I'm on a small budget)
: 
: Someone has provided a Rexx interface to ARCSGML for use with
: Personal Rexx under MS-DOS.  With this, you could fairly easily
: write "query" applications.  The basic idea is
: to first define the data structures you need to hold the data
: you want, just as you would for any other data processing
: application.  You then process the document, grabbing data
: off of the relevant elements as they go by and putting it into your data
: structures.  The rest you just let flow through and ignore.

In the distribution of sgmls 1.0, there is a Perl skeleton script that 
"parses" the output of sgmls. You just have to insert the code you want 
into this skeleton script to write an application.

(more sutff deleted)

: <digression>
: 
: The examples above, and most SGML applications in existence today,
: process SGML documents sequentially from start to finish.  However,
: SGML does not require sequential processing, and it can make just
: as much sense to define applications that work with SGML documents
: wholistically as a tree, rather than sequentially, at
: least in the abstract.  In this processing model, access is
: via queries, rather than sequential access by waiting for the
: element you want to flow by.  Some SGML-based online presentation
: systems, such as EBT's Dynatext, present this sort of view of
: documents, providing query-based direct access to elements and
: and data, which makes sense in a dynamic, direct access application
: like online presentation.

I think this is a very good point, and I believe that the next generation SGML
parsers have to move away from the sequential processing model. Some probably
have, such as SGML parsers for SGML editors.  In any HyTime application, 
there will be communications between the application, HyTime engine, and 
the SGML parsers. This communication will in most cases be non-sequential.
Hence, I think an SGML parser using the processing model that Eliot described
will be much more powerful.

(even more stuff deleted)

: Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
: Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
: Network Programs Information Development     Phone: 1-919-543-7091
: IBM Corporation
: Research Triangle Park, NC 27709

--
   Bernd Nordhausen (bernd@iss.nus.sg)
   Institute of Systems Science                           Ph: +65 772-6240 
   National University of Singapore                      FAX: +65 778-2571
   Singapore 0511
From: drmacro@ralvm13.VNET.IBM.COM
Date: Tue, 5 Jan 93 09:26:12 EST
Newsgroups: comp.text.sgml
Subject: Re: FrameBuilder
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1

In <1993Jan5.074304.1652@gmd.de> Tom Gordon, I3.KI 2665 writes:
>Has anyone had a chance to try FrameBuilder, the SGML version of FrameMaker,
>who would be willing to share their first impressions?
>

FrameBuilder was demonstrated at SGML '92 and I spent some time
looking at it and talking to the folks from Frame.  It was
difficult to judge how its SGML support really works, so I can't
comment on what features of SGML it actually supports, or how,
but I must say that the interface looked very good.  The mechanism
they have for working with structures seemed very well thought
out and intuitive.  It seems to hold some promise for being a
truly WYSIWYG SGML authoring system.  The Framemaker product
is already a very strong competitor in the WYSIWYG (non-SGML)
arena, so one could reasonably expect that function to carry
over.  The test will be how much of SGML is actually supported,
a question to which I don't know the answer.  Will it, for
example, manage marked sections and entity declarations for
you?  Will it automatically manage ID and IDREF attributes?
Does it support CONREF?  What parser does it use?   How
difficult is it to adapt to a particular DTD or set of
application-specific processing semantics?  How does it support
tables?  How is presentation style specified, in some non-SGML,
proprietary way or using an SGML style document like FOSI?

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709
Newsgroups: comp.text.sgml
From: U35395@uicvm.uic.edu (C. M. Sperberg-McQueen)
Newsgroups: comp.text.sgml
Subject: Re: Precedence of SGML Operators?
Date: 5 Jan 93 20:20:04 GMT
Organization: University of Illinois at Chicago

Erik Naggum writes:
> ... which in a different language could have
> been explained by some arcane precedence rules at work; however, SGML
> has no notion of operators or of operator precedence rules as these
> terms are used in programming languages.

I think EN strains things a bit here, with potentially misleading
results.  SGML indeed has 'no notion of [...] operator precedence' but
this does not mean Holger Rath's query was ill-formed!  The fact that
SGML expresses its operator precedence rules in its formal grammar
rather than in separate rules (as for example yacc does) does not mean
SGML has no operator precedence, only that its operator precedence
rules are implicit.

The analyses posted already seem to me to hit the case:  looks like
a bug in Mark-It.

By the bye:  EN's remarks might lead one to believe that other SGML
parsers don't have bugs; that would be a wrong conclusion.  Certainly
most of the ones I've used have a problem here or there.

-C. M. Sperberg-McQueen
 ACH / ACL / ALLC Text Encoding Initiative
 University of Illinois at Chicago
Newsgroups: comp.text.sgml
From: jrutledg@cs.ulowell.edu (John Lawrence Rutledge)
Subject: Re: FrameBuilder
Organization: University of Massachusetts at Lowell Computer Science
Date: Mon, 11 Jan 1993 17:59:55 GMT

In article <ROBIN.93Jan10111434@utafll.utafll.uta.edu> robin@utafll.uta.edu (Robin Cover) writes:
>The description of FrameBuilder's "SGML support" by Peter Cash is a
>major stunner, if it is accurate.  The Fall issue of <title>Frame
>Focus</> had a lead article "Frame Joins Forces with Datalogics" which
>said, among other things:
>
>     FrameBuilder provides full, native support for Standard
>     Generalized Markup Language (SGML), a widely adopted ISO
>     standard for document interchange.
>

I got the some line from a sales rep at UNIX EXPO back in September.  So I
arranged to become a beta test site.  Unfortunatity I found out after 
getting the product and the manuals, this "full, nativbe support" only 
means it incorperates the concept of structure, but nothing more.  

FrameBuilder allows the user to define, in SGML like sematics, the structure
of the document.  This structure definition contains all the basic operators
including inclusions and exclusions.  But even this violates the standard
in minor ways.  The generic identifiers used in their "DTD" can have up to
256 characters (the standard says eight) and can contain spaces.

The major problem with using FrameBuilder for my purposes is that there
is no support for attributes are even reading SGML files.  If you use
FrameBuilder as it now stands, you cannot use SGML as well.

+-----------------------------+-----------------------------------------------+
|			      |  "If only it were a modern document, with a   |
| John Lawrence Rutledge      | smart index and hyper links stretching all    |
| Research Assistant	      | through the world data net.  It was terribly  |
| 			      | frustrating to flip back and forth between    |
| Interactive Media Group     | the pages and crude flat illustrations that   |
| Computer Science Department | never even moved.  Nor were there animated    |
| U of Mass - Lowell          | arrows or zoom-ins.  It completely lacked a   |
| 1 University Ave.	      | for sound.                                    |
| Lowell, MA 01854            |  "Most baffling of all was the problem of new |
|			      | words...  In normal text you'd only have to   |
| (508) 934-3611	      | touch an unfamiliar word and the definition   |
| jrutledg@cs.ulowell.edu     | would pop up just below."                     |
|			      |    	           from David Brin's "Earth"  |
+-----------------------------+-----------------------------------------------+







-- 
+-----------------------------+-----------------------------------------------+
|			      |  "If only it were a modern document, with a   |
| John Lawrence Rutledge      | smart index and hyper links stretching all    |
| Research Assistant	      | through the world data net.  It was terribly  |
Newsgroups: comp.text.sgml
From: thomas@gmd.de (Tom Gordon, I3.KI 2665)
Subject: FrameBuilder
Reply-To: thomas@gmd.de
Organization: GMD, Sankt Augustin, Germany.
Date: Tue, 5 Jan 1993 07:43:04 GMT

Has anyone had a chance to try FrameBuilder, the SGML version of FrameMaker,
who would be willing to share their first impressions?


---
Thomas F. Gordon
GMD, FIT; Artificial Intelligence Research Division
5205 Sankt Augustin 1 / Germany
email: thomas.gordon@gmd.de;  phone: (+49 2241) 14-2665

Newsgroups: comp.text.sgml
From: Erik Naggum <SGML@ifi.uio.no>
Date: 05 Jan 1993 02:31:49 +0100
Subject: Re: SGML

[Paul Prescod]
|
|   I really don't know much about sgml except what it's for.  I *DO*
|   however know what I would use it for.  But i need to know one thing:
|
|   Is there any standard for SGML wherein the text is seperated from the
|   formatting codes, so that for those that have no interest in SGML the
|   text is not mangled?

There are no _formatting_ codes in SGML documents to begin with.  (OK,
so I'm being pedantic, but it's an important point, often overlooked.)

Those who have no interest in SGML should use an SGML-aware editor that
doesn't display the markup, but instead uses some locally meaningful
form of presentation for the individual elements.  Note that formatting
is not in the scope of SGML, although formatting is certainly one of the
things to which you could subject an SGML document.

If you wish to separate the markup from the text completely, you will
need to establish a means to identify the start and end of all elements
in the separated text.  This is certainly _possible_, but you wouldn't
want to do it, because you would end up with more things to take care of
than writing an SGML-aware editor from scratch.

Some of us don't think text is "mangled" by SGML-type markup, but that
may be because we actually know the language, and use it to keep markup
at the level where it is still informative to us.  (It follows that I,
at least, don't use any SGML-"aware" editor, either -- they invariably
know less about SGML than I do and that's frustrating, especially when
they're wrong and being _very_ stubborn about it.)

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
Newsgroups: comp.text,comp.os.msdos.apps,comp.os.msdos.misc,comp.os.os2.misc,comp.editors,comp.text.desktop