<message id="<19960227T063534Z@arcana.naggum.no>" date="3034391735" seqno="12738">
From: Erik Naggum \<erik@naggum.no>
Newsgroups: comp.text.sgml
Subject: Re: Backwards compatible SGML (Was: Can Entities be specific to certain Elements?)
Date: 27 Feb 1996 06:35:35 +0000
Organization: Naggum Software; +47 2295 0313
Message-ID: <19960227T063534Z@arcana.naggum.no>
References: \<pepper.16.00AAE6C4@falch.no> <4gshoa$rqu$1@mhafc.production.compuserve.com>

[Raymond H. Stachowiak]

|   We cannot simple change the standard and now say we have old data that
|   conforms to 1986 and new data that conforms to 200x.

please provide some arguments for why we cannot do this.

|   When we upgrade the standard we need to provide support in an upwardly
|   compatible manner.

please provide some arguments for why this is necessary.

|   Further we need to support all the features people use or provide an
|   alternative that can be programmatically supported.

please explain why you think the current standard and its crop of software
will evaporate when the new edition of the standard is published.  please
explain why you think the presence of a new edition of a standard will make
the whole world change overnight.

|   You cannot ignore the wealth of data which supports the existing
|   structures.

who are you arguing against?  has anybody said this, implied this, or in
any way communicated this to you?  no.  do you know what those who want to
change the standard want to do?  no.  do you see any impending changes to
the standard being adopted in a hurry?  no.

do you seriously think that we who have spent years of our lives with SGML,
working for the improved well-being and life expectance of information,
will forget all the arguments that we have ourselves made in the past?  no?
then why do you fear changes you don't even know?

please save your fear until you know what is going to be changed and how it
will affect your information.  if you intend to block progress out of fear
alone, please make certain that you don't kill the information you try to
save, by making SGML irrelevant for those who wish to keep theirs alive and
kicking.  SGML is already facing so stiff competition from both software
and other standards that it cannot continue to sit on its high horse and
proclaim itself the winner just because it won over still-born standards
such as ODA.

the old standard will remain unchanged, software will still conform to it,
and old data will continue to conform to it.  please relax.  there is not
going to be a seriously revised edition of SGML for another three
generations of hardware and today's market leaders may well be gone by the
time it is published.  the revised SGML will be designed to handle the
information needs that arise a decade from now.

if you wish to limit the future to what you couldn't even imagine a decade
ago, you're no friend of the information.  fear of change is an illness.

I gave a poster session at SGML 1994 that tried to alert people to some of
the issues of longevity in SGML.  see ftp://ftp.naggum.no/pub/SGML94/.

#\<Erik 3034391734952593>
-- 
the Internet made me do it
</message>
<message id="<9602271242.AA15298@fly.HiWAAY.net>" date="3034413773" seqno="12739">
Newsgroups: comp.text.sgml
Date: Tue, 27 Feb 1996 06:42:53 -0600
Message-ID: <9602271242.AA15298@fly.HiWAAY.net>
From: Len Bullard \<cbullard@HiWAAY.net>
Subject: Re: Backwards compatible SGML

[Steve Pepper]

>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?

They say:

1.  Give us tools at a price we can afford.

2.  Give us tools we can use without a six-month course in parsing theory
    just so we can create documents we can create in MS-WORD in ten
    minutes.

3.  Give us tools that allow us to specify DTDs AND style.

4.  Give us tools that allow us to specify weak and strong links.

5.  Give the programmers a language so they are able to build and support
    tools without a six-month course in SGML terminology.

6.  Give us a language that works without apologies.

We don't want much.  But we want it now.  ;-)

Len Bullard
</message>
<message id="<199602271525.QAA17669@cygne.ais.berger-levrault.fr>" date="3034423507" seqno="12740">
Newsgroups: comp.text.sgml
Date: Tue, 27 Feb 1996 16:25:07 +0100
From: Francois Chahuneau \<fcha@Berger-Levrault.fr>
Message-ID: <199602271525.QAA17669@cygne.ais.berger-levrault.fr>
References: <4gbtcc$mba@news-s01.ny.us.ibm.net> <4gi16r$rou@maroon.tc.umn.edu> <4gkg3f$vh@cliffy.lfwc.lockheed.com> <3130BA17.67E6@iconn.net>
Subject: Re: [Q] SGML mapping to RDBMS - SGML storage 

[Paul Hayslett]

> Has anyone tried the totally naive approach of just storing SGML docs as
> parse trees?

Congratulations!  What you describe is almost exactly the architecture of
the SGML/Store system.  The logical table schema you suggest is close to
the right one, but you should not believe that this can be implemented upon
commercially available SQL-based RDBMS with reasonable performance (if you
want to use more than toy data sets).

SGML/Store is currently implemented in a proprietary way on a low-level
B-tree library.  All attempts to re-implement it as a RDBMS (Oracle V6,
Ingres) or OODB (O2, Matisse) application resulted in catastrophic
performance, either in terms of response times, disk expansion factor, RAM
consumption, or a combination of those.  Reasons are complex, but relate to
the same reasons why RDBMS where found largely inadequate for CAD-CAM
database design.  With SGML documents, the problem is just one order of
magnitude tougher.

Just think that an average ATA-encoded Aircraft Maintenance Manual contains
more that 1.5 million SGML elements and about as many attributes.  Each of
those tiny objects hold no more that 10 to 100 bytes of information.  On
RDBMS, the transitive closure you have to perform to rebuild a chapter
represents a formidable number of elementary SQL queries.  Using cursors is
feasible, but generates lots of RAM consumption.  As far as OODBMS are
concerned, most of them are optimzed for storing an average number of large
objects rather than a huge number of very small objects, considering the
usually high overhead for object storage.
</message>
<message id="<4guvr3$e1e@cliffy.lfwc.lockheed.com>" date="3034415395" seqno="12741">
From: mcclellantj@harrier (Tad McClellan)
Newsgroups: comp.text.sgml
Subject: Re: Backwards compatible SGML (Was: Can Entities be specific to certain Elements?)
Date: 27 Feb 1996 13:09:55 GMT
Organization: Lockheed Martin Tactical Aircraft Systems
Message-ID: <4guvr3$e1e@cliffy.lfwc.lockheed.com>
References: \<pepper.16.00AAE6C4@falch.no> <4gshoa$rqu$1@mhafc.production.compuserve.com> <19960227T063534Z@arcana.naggum.no>
Reply-To: mcclellantj@lfwc.lockheed.com

Erik Naggum (erik@naggum.no) wrote:
: [Raymond H. Stachowiak]

: |   We cannot simple change the standard and now say we have old data that
: |   conforms to 1986 and new data that conforms to 200x.
                                                     ^^^^

: who are you arguing against?  has anybody said this, implied this, or in
: any way communicated this to you?  no.  do you know what those who want to
: change the standard want to do?  no.  do you see any impending changes to
: the standard being adopted in a hurry?  no.
                     ^^^^^^^^^^^^^^^^^^

I just hope we don't need to be saying 20xx.   ;-)

--
  Tad McClellan,      Logistics Specialist (IETMs and SGML guy)
                      email: mcclellantj@lfwc.lockheed.com
  All I want, is a little more than I'll ever get.
</message>
<message id="<31334ABE.57C3@passage.com>" date="3034433854" seqno="12742">
From: "W. Eliot Kimber" \<kimber@passage.com>
Newsgroups: comp.text.sgml
Subject: Re: Backwards compatible SGML (Was: Can Entities be specific to certain Elements?)
Date: Tue, 27 Feb 1996 09:17:34 -0900
Organization: Passage Systems Inc.
Message-ID: <31334ABE.57C3@passage.com>
References: \<pepper.16.00AAE6C4@falch.no> <4gshoa$rqu$1@mhafc.production.compuserve.com> <19960227T063534Z@arcana.naggum.no>

Erik Naggum wrote:
 
> the old standard will remain unchanged, software will still conform to it,
> and old data will continue to conform to it.  please relax.  there is not
> going to be a seriously revised edition of SGML for another three
> generations of hardware and today's market leaders may well be gone by the
> time it is published.  the revised SGML will be designed to handle the
> information needs that arise a decade from now.

I understand Erik's point and to some degree agree with him, at least in 
principle. While Erik is correct that there's no reason that two versions of 
SGML couldn't co-exist, I think there are some practical reasons for wanting 
to avoid having a revised SGML that is not backward compatible with 
ISO 8879:1986:

o Tool vendors may not be willing to develop and support two versions of 
their tools, which they would be under pressure to do.

o Groups using SGML may not be willing to maintain two sets of tools to 
support their (now) legacy SGML and information conforming to the new SGML.
And new tools also mean new knowledge and training.

o Enterprises may not be willing or able to migrate existing information 
bases to the new standard, requiring either two tool paths or limiting new 
information to the older standard, precluding the use of attractive new 
features in the new standard.

On the other hand, as Erik and others have pointed out on many occasions, 
there are some features of SGML that are rarely used and that the elimination 
of which would tend to make SGML simpler to process. If a decision was made 
to violate the "no breakage" rule, it would probably be done so as to affect 
the fewest existing documents (hint: if your business depends on CONCUR or 
DATATAG, speak up now). But that's a big if.

I think that most of what we want to do to improve SGML can be done without 
breaking existing documents. Most of it involves adding new features to SGML 
or providing a finer level of granularity in what features are optional (for 
example, it might make sense to make optional features of those aspects of 
SGML that make it more difficult to write parsers for).

I must also say that I don't share Erik's fear of other technologies eroding 
SGML's appeal. HTML certainly won't, and I don't see any other standard or or 
proprietary format that even comes close to meeting the requirements that 
SGML does. While I'm sure Erik's correct that *more* people would use SGML if 
it were easier to parse, I don't think that anyone is *not* using SGML for 
whom it's use would be a significant advantage because it's not as easy to 
parse as it could be (after all, there are sufficient free tools of very high 
quality if you want to use them and a number of commercial tools of high 
quality at a reasonable price).

My take is that the world needs something like SGML. It has SGML. It seems 
unlikely that anyone will develop anything to compete with SGML because to do 
so would require duplicating the develop of SGML itself (remember that to 
compete with SGML it has to be standard with authority equivalent to an 
ISO/IEC standard, since long-term stability is one of SGML's key 
requirements). Thus, while I want to see SGML improved as quickly as 
possible, I don't feel the same sense of change-or-die urgency that Erik 
does. Perhaps that's naive of me, but so far my experience has not suggested 
otherwise. 

-- 
\<Address HyTime=bibloc>
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
\</Address>
"Mr. Thought Policeman, I don't wanna do no wrong..." -- "1984 Blues", 
Austin Lounge Lizards (http://www.webcom.com/~yeolde/all/lllhome.html)
</message>
<message id="<4gv4lv$oep@newsbf02.news.aol.com>" date="3034420351" seqno="12744">
From: nomuraent@aol.com (NomuraEnt)
Newsgroups: comp.text.sgml
Subject: Re: [Q] SGML mapping to RDBMS - SGML storage
Date: 27 Feb 1996 09:32:31 -0500
Organization: America Online, Inc. (1-800-827-6364)
Sender: root@newsbf02.news.aol.com
Message-ID: <4gv4lv$oep@newsbf02.news.aol.com>
References: <4gbtcc$mba@news-s01.ny.us.ibm.net>
Reply-To: nomuraent@aol.com (NomuraEnt)

I also would suggest trying LivePage.  We've got it and it's a great
product. It handles the loading of the SGML into the relational database
and the retrieval  and it has an API so you can customize the front-end
and queries.


Michael Pash
Nomura Enterprise Inc
NomuraEnt@aol.com
</message>
<message id="<4gv3p2$lfc@news-sop.inria.fr>" date="3034419426" seqno="12745">
From: lapalut@tao.inria.fr (Stephane Lapalut)
Newsgroups: comp.text.sgml
Subject: where: SGML/TEI viewer on Macintosh ?
Date: 27 Feb 1996 14:17:06 GMT
Organization: INRIA Sophia-Antipolis
Message-ID: <4gv3p2$lfc@news-sop.inria.fr>
Reply-To: lapalut@sophia.inria.fr

 Hello,

 I wish to know if there exists a free/shareware to read SGML/TEI documents ?
 I know arcsgml (even if I have not been able to find the macintosh archive),
 but it need to be compiled on macintosh, which is not possible from my part.

 All kind of advices/informations welcome!

 thanks,

Stephane


DISCLAIMER: opinions expressed here are only mime, unless specified
----------
S. Lapalut, projet ACACIA                Voice: (+33) 9365 7645
INRIA, BP 93 2004 route des Lucioles     Fax:   (+33) 9365 7783
06902 Sophia Antipolis cedex France
</message>
<message id="<3133450C.5275@passage.com>" date="3034432396" seqno="12746">
From: "W. Eliot Kimber" \<kimber@passage.com>
Newsgroups: comp.text.sgml
Subject: Re: DSSSL compliance
Date: Tue, 27 Feb 1996 08:53:16 -0900
Organization: Passage Systems Inc.
Message-ID: <3133450C.5275@passage.com>
References: <3132D49A.B78@mch.sni.de>

Wilfried Wiehler wrote:
> 
> Just another question:
> 
> I am wondering if there are any tools that are more or less DSSSL
> compliant.
> Background is that I worked with InContext and Panorama and their
> approach to styles is totally different.

Check out Alex Milowski's SENG tool, 
(http://www.winternet.com/~sgml/seng/index.html). SENG is a DSSSL-based 
transformation tool. One of the sample applications is similar to what you 
asked for in your earlier post (mapping elements to fielded output).

-- 
\<Address HyTime=bibloc>
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
\</Address>
"Mr. Thought Policeman, I don't wanna do no wrong..." -- "1984 Blues", 
Austin Lounge Lizards (http://www.webcom.com/~yeolde/all/lllhome.html)
</message>
<message id="<4gv3dm$1r9@Venus.mcs.com>" date="3034419062" seqno="12747">
From: jorn@MCS.COM (Jorn Barger)
Newsgroups: comp.text.sgml,alt.hypertext
Subject: THEORY: Definition links (Was: Strongly-Typed Hyperlinks)
Date: 27 Feb 1996 08:11:02 -0600
Organization: The Responsible Party
Message-ID: <4gv3dm$1r9@Venus.mcs.com>
References: <31164A18.25C4@passage.com> <4ggfks$nup@gap.cco.caltech.edu> <4ghsps$bce@Mercury.mcs.com> <4gs61m$2ur@wapping.ecs.soton.ac.uk>
Summary: the lingering cost of *not* following the link


There's another problem with definition-links that I think is getting
overlooked...

We've talked about:

- Latency: if it takes too long for a definition to be retrieved, it's
  probably better to put it inline, or at least on the same page

- Markup: it's inefficient to mark every occurence of a defined term with
  a definition link

- Page layout: highlighting defined terms can be distracting

- Disorientation: a popup window imposes a cost in disorientation

- Custom/Generic definitions: a universal dictionary will be less
  useful than a customized glossary for a given document

- Alternatives: inline definitions, or a convention about where to
  look for definitions, are other alternatives


But there's another one, that I think falls the farthest *outside*
the normal style of thinking about hypertext:

When a reader is made aware that a definition is available, *it's
not a simple question whether it will be worth visiting*.  The
standard way of thinking seems to be: either you already know the
definition, or you don't, and only those who don't will need to
follow the definition link.

But what I find on the WWWeb-- that *only* becomes apparent in such
a context-- is that you never feel confident that you're not *missing
something* by skipping the definition!

Especially if you're dealing with a talented writer (something that
never seems to enter into conventional hypertext theory, significantly ;^/  
there's a serious 'cognitive overhead' in *skipping* the definition,
just because you're never *that* secure that it wasn't worth a look...

My inclination, as a result, is to view definitions as something that
the writer should handle, as a literary-style problem, and that the
only role for popup definitions is via an independent dictionary-
utility on the reader's machine, that sits in the background with
all applications, and retrieves the definition of a highlighted word
when you hit a particular hot-key...


j

-==---
. hypertext theory : artificial intelligence : finnegans wake . _+m"m+_"+_ 
             lynx http://www.mcs.net/~jorn/ !             Jp   Jp     qh qh
          best-of news:alt.music.category-freak !         O    O       O  O
           ftp://ftp.mcs.com/mcsnet.users/jorn/           Yb   Yb     dY dY
...do you ever feel your mind has started to erode?        "Y_  "Y5m2Y"  "  no.

</message>
<message id="<3132A0A2.7870@passage.com>" date="3034390306" seqno="12748">
From: "W. Eliot Kimber" \<kimber@passage.com>
Newsgroups: comp.text.sgml
Subject: Some Cool SGML Stuff
Date: Mon, 26 Feb 1996 21:11:46 -0900
Organization: Passage Systems Inc.
Message-ID: <3132A0A2.7870@passage.com>

Came across the Berkley Finding Aid Project 
(http://library.berkeley.edu:80/AboutLibrary/Projects/BFAP/) in the 
course of doing a Web search. Here is the first paragraph from their 
home page:

"The Berkeley Finding Aid Project is a collaborative endeavor to test 
the feasibility and desirability of developing an
encoding standard for archive, museum, and library finding aids. Finding 
aids are documents used to describe, control,
and provide access to collections of related materials. In the 
hierarchical structure of collection-level information access
and navigation, finding aids reside between bibliographic records and 
the primary source materials. Bibliographic records
lead to finding aids, and finding aids lead to primary source materials. 
A standard for encoding finding aids will ensure
not only broad based access to our cultural heritage and natural history 
collections, but that the findings aids themselves
will survive hardware and software platform changes, and thereby remain 
available for future generations."

I hadn't heard about this, so it took me by surprised. I think it's 
pretty cool for at least the following reasons:

a) It shows how sophisticated SGML browsers (e.g., Panorama) can provide 
a significantly better result than HTML for database-ish information 
like finding aids.

b) It shows how SGML can be used effectively to structure database-ish 
information like finding aids.

c) My wife is a PhD candidate in history, so these finding aids are a 
tool she desperately needs to do her work. It's cool when the nerdish 
work you do has some relevance to your better half's life beyond paying 
the bills.

Dr. Macro says check it out.

-- 
\<Address HyTime=bibloc>
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
\</Address>
"Mr. Thought Policeman, I don't wanna do no wrong..." -- "1984 Blues", 
Austin Lounge Lizards (http://www.webcom.com/~yeolde/all/lllhome.html)
</message>
<message id="<4gtuis$6i@blackice.winternet.com>" date="3034381340" seqno="12749">
From: sgml@subzero.winternet.com (Copernican Solutions Incorporated)
Newsgroups: comp.text.sgml
Subject: SGML revision?
Date: 27 Feb 1996 03:42:20 GMT
Organization: Winternet Corporation, Mpls, MN
Message-ID: <4gtuis$6i@blackice.winternet.com>

Hello all,
 
What's up with the SGML revision?  Could someone post a followup letting
us know what is being considered and what has been tentatively decided?

==============================================================================
R. Alexander Milowski     http://www.winternet.com/~sgml  sgml@winternet.com
Copernican Solutions Incorporated                           (612) 825 - 4132
--
==============================================================================
R. Alexander Milowski     http://www.winternet.com/~sgml  sgml@winternet.com
Copernican Solutions Incorporated                           (612) 825 - 4132
</message>
<message id="<3132D265.1822@mch.sni.de>" date="3034403045" seqno="12750">
From: Wilfried Wiehler \<Wilfried.Wiehler@mch.sni.de>
Newsgroups: comp.text.sgml
Subject: [Q]Conversion into 'plain' SGML
Date: Tue, 27 Feb 1996 10:44:05 +0100
Organization: Siemens Nixdorf AG
Message-ID: <3132D265.1822@mch.sni.de>

Could anyone give me advice to the following:

I need to convert any SGML documents into a 'plain' format that would
look like the following:
	(tag1?, tag2?, tag3?,...)
It should be possible to assign one or more source text components to
one or more destination components.

I have played a little bit with Omnimark, and think it would be easy to 
write a program for each DTD, but perhaps there is an easier way, e.g. by 
using the output of a parser.

Thanks for any help,
Wilfried

-- 
Wilfried Wiehler	Tel:	#49-89-636-43093
SNI ASW BA GV/SDP	Fax:	#49-89-636-41344
Otto-Hahn-Ring 6	GV:	Wilfried Wiehler:MCHP08:SNI-DS
D-81739 Muenchen 	IN:	Wilfried.Wiehler@mch.sni.de
</message>
<message id="<3132D49A.B78@mch.sni.de>" date="3034403610" seqno="12751">
From: Wilfried Wiehler \<Wilfried.Wiehler@mch.sni.de>
Newsgroups: comp.text.sgml
Subject: DSSSL compliance
Date: Tue, 27 Feb 1996 10:53:30 +0100
Organization: Siemens Nixdorf AG
Message-ID: <3132D49A.B78@mch.sni.de>

Just another question:

I am wondering if there are any tools that are more or less DSSSL 
compliant.
Background is that I worked with InContext and Panorama and their 
approach to styles is totally different.

Again thanks for any help,
Wilfried

-- 
Wilfried Wiehler	Tel:	#49-89-636-43093
SNI ASW BA GV/SDP	Fax:	#49-89-636-41344
Otto-Hahn-Ring 6	GV:	Wilfried Wiehler:MCHP08:SNI-DS
D-81739 Muenchen 	IN:	Wilfried.Wiehler@mch.sni.de
</message>
<message id="<3133927F.32AD@cs.utas.edu.au>" date="3034452223" seqno="12752">
From: John Lamp \<John.Lamp@cs.utas.edu.au>
Newsgroups: comp.text.sgml
Subject: Re: Need SGML FAQ
Date: Wed, 28 Feb 1996 10:23:43 +1100
Organization: Information Systems Group
Message-ID: <3133927F.32AD@cs.utas.edu.au>
References: \<sewell.26.00111D20@as.tt.ba-ravensburg.de>
Reply-To: John.Lamp@cs.utas.edu.au

Michael Sewell wrote:
> 
> If there is one can someone post me the SGML newsgroup FAQ, as I am just
> starting research in this direction. Thank you.

You'll have to have a look in the ftp archive at 
ftp://ftp.ifi.uio.no/pub/SGML/ but there are other links at 
http://lamp.cs.utas.edu.au/net.html which might be useful.

This raises another question. At present, there is no regular posting 
of the FAQ. I am happy to set up a cron job here to look after that. 
But I have also seen various SGML FAQs -- which one is considered the 
definitive FAQ?

-- 
Cheers
John
--
   _--_|\\             John Lamp, originating in Hobart, Tasmania
  /      \\                 Phone: 002 20 2375 - Fax: 002 20 2913
  \\_.--._/                       email: John.Lamp@cs.utas.edu.au
        v <--<<          http://lamp.cs.utas.edu.au/jw_lamp.html
Information Systems Group, Dept of Comp Science, Uni of Tasmania
</message>