[comp.text.sgml] FTP defn of SGML

bzs@world.std.com (Barry Shein) (09/28/90)

>Does anyone know if there is an ftp-able definition of SGML.  I would
>prefer a BNF definition if one is available.  Thanks.

As near as I can tell the ISO standard is copyright and forbids this
type of thing, otherwise I'd put it up (I have the docs.)

I suppose someone could cobble up their own definition but isn't that
ducky, since any differences from the standard would be suspect, and
if it were exactly like the standard it would violate copyright (!)

Can't wait until someone copyrights PI...
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

enag@ifi.uio.no (Erik Naggum) (09/28/90)

In article <BZS.90Sep27170601@world.std.com>, Barry Shein writes:

   I suppose someone could cobble up their own definition but isn't that
   ducky, since any differences from the standard would be suspect, and
   if it were exactly like the standard it would violate copyright (!)

Would a BNF spec of SGML be considered as a "derived work", or a
sufficiently "original work" with respect to the reg-exp style spec in
the ISO docs?

I, too, have found the reg-exp style more than a little hard to read
and use.  Joan Smith's User Guide helps a lot, but still retains the
presentation style.

Once I get a little free time and can take a break, I will look into
the desirablity of representing the SGML in BNF, in more detail, and
try my hand at doing some experimental work.  Don't hold your breath.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427

ath@prosys.se (Anders Thulin) (09/28/90)

In article <BZS.90Sep27170601@world.std.com> bzs@world.std.com (Barry Shein) writes:

>As near as I can tell the ISO standard is copyright and forbids this
>type of thing, otherwise I'd put it up (I have the docs.)

Well, they'll certainly come down on any unauthorized copying. Does
anyone know what it would cost to get an authorization?

-- 
Anders Thulin       ath@prosys.se   {uunet,mcsun}!sunic!prosys!ath
Telesoft Europe AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

jwh@boston.ifs.umich.edu (Jim Howe) (09/28/90)

In article <BZS.90Sep27170601@world.std.com>, bzs@world.std.com (Barry
Shein) writes:
|> 
|> >Does anyone know if there is an ftp-able definition of SGML.  I would
|> >prefer a BNF definition if one is available.  Thanks.
|> 
|> As near as I can tell the ISO standard is copyright and forbids this
|> type of thing, otherwise I'd put it up (I have the docs.)
|> 

Do you know if you can get a machine readable version of the standard from ISO?


James W. Howe			   internet: jwh@ifs.umich.edu
University of Michigan             uucp:     uunet!mailrus!ifs.umich.edu!jwh
Ann Arbor, MI   48103-4943         

enag@ifi.uio.no (Erik Naggum) (09/29/90)

In article <1990Sep28.134332.24815@terminator.cc.umich.edu> jwh@boston.ifs.umich.edu (Jim Howe) writes:

   Do you know if you can get a machine readable version of the
   standard from ISO?

Yes, and the answer is unfortunately NO.  I learned that they do not
even have machine-readable versions in-house, and that drafts are most
often type-set anew for each version.  The same goes for CCITT, which
is another paper-based standardizing body in the field of electronic
information.  Amazing.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427

bzs@world.std.com (Barry Shein) (09/29/90)

It's too bad we as a community don't stand up and say "If it isn't
on-line, it isn't a standard".

How much can they possibly be making on reprints of this stuff? This
ain't exactly NY Times booklist stuff.

I'd certainly be happy with something that restricted anyone from
making money directly from reproducing the text, a reference-only,
on-line copyright.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/29/90)

jwh@ifs.umich.edu writes:
> bzs@world.std.com (Barry Shein) writes:
>|> 
>|> >Does anyone know if there is an ftp-able definition of SGML.  I would
>|> >prefer a BNF definition if one is available.  Thanks.
>|> 
>|> As near as I can tell the ISO standard is copyright and forbids this
>|> type of thing, otherwise I'd put it up (I have the docs.)
>|> 

>Do you know if you can get a machine readable version of the standard
>from ISO?

Sigh. I guess this needs saying at least once in each group that
interacts with standards bodies and their documents. My apologies
to those who've read my four or five similar postings over the
years.

Standards bodies want to control the documents to assure
consistency among the copies in circulation, which can't be done
with (essentially immortal and infinitely mutable) machine
readable copies handed around by private distribution channels (a
nicer term for piracy).

Standards bodies pay a substantial portion of their administrative
costs with the income from their sale of paper standards
documents, in draft as well as final form.

From these causes, several things result.

1) The price of the documents is far higher than the price of
similar documents of similar publishing quality.

2) The documents are copyrighted, and the copyrights vigorously
pursued.

3) The world's habits of passing around machine readable text in
indiscriminate fashion without regard for copyright being well
known, machine readable versions are treated like the Crown
Jewels. Letting one copy out is the practical equivalent of
nullifying the income from the corresponding paper document.

4) Review of standards in work, and compliance with standards when
complete, are limited to those who can/will pay the cost of paper
copies.

5) Incorporation of out-takes from standards documents in ones own
writing requires retyping, with possible insertion of additional
errors.

And so it goes. Send them a check. By doing so, you help fund
future standards efforts.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

hrs1@cbnewsi.att.com (herman.r.silbiger) (09/29/90)

In article <ENAG.90Sep28043321@hild.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
> Once I get a little free time and can take a break, I will look into
> the desirablity of representing the SGML in BNF, in more detail, and
> try my hand at doing some experimental work.  Don't hold your breath.
> 
Take a look at ISO 8613, and compare the ASN.1 specification of ODA (ODIF)
with the ODL specification (ODIF in SGML).

Now tell me which is easier to read.

Of course ODL is tied to the ODA architecture, but I don't see any reason
why a ASN.1 version of SGML could not be done.  It might be useful to have a
way of specifying non-hierarchical architectures in a BNF notation.

Herman Silbiger
hsilbiger@attmail.com

jwh@jackpot.ifs.umich.edu (Jim Howe) (09/29/90)

In article <1990Sep29.003132.17644@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>jwh@ifs.umich.edu writes:
>> bzs@world.std.com (Barry Shein) writes:
>>|> 
>>|> >Does anyone know if there is an ftp-able definition of SGML.  I would
>>|> >prefer a BNF definition if one is available.  Thanks.
>>|> 
>>|> As near as I can tell the ISO standard is copyright and forbids this
>>|> type of thing, otherwise I'd put it up (I have the docs.)
>>|> 
>
>>Do you know if you can get a machine readable version of the standard
>>from ISO?
>
>Sigh. I guess this needs saying at least once in each group that
>interacts with standards bodies and their documents. My apologies
>to those who've read my four or five similar postings over the
>years.
>
>[lecture deleted]
>

Give me a break.  All I was asking for was a machine readable form
of the SGML standard e.g. BNF description.  I wasn't asking for a
machine readable version of the Standard document which includes
all the descriptions of the various elements contained in the 
grammar.  Secondly I never said I wouldn't pay for a machine readable
version of the standard.  If it was freely available that would
be better but I would rather pay a small fee than to try to manually
enter the standard.




James W. Howe			   internet: jwh@ifs.umich.edu
University of Michigan             uucp:     uunet!mailrus!ifs.umich.edu!jwh
Ann Arbor, MI   48103-4943         

bzs@world.std.com (Barry Shein) (09/30/90)

From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan)
>Standards bodies want to control the documents to assure
>consistency among the copies in circulation, which can't be done
>with (essentially immortal and infinitely mutable) machine
>readable copies handed around by private distribution channels (a
>nicer term for piracy).

Well, this is just bureaucratic fluff. Let them attach a checksum or
whatever. Anyhow, you gets what you pays for.

Worries of mutability is an attack on the entire concept of on-line
documents. Do you have/see this problem with Unix manual pages, as an
example? That has to be solved separately, not by tossing out the
whole concept.

I would claim one of the major reasons for the success of DARPA
Internet standards was their wide, machine-readable availability.

And, similarly, I'd claim that the opposite effect for many ISO
standards (e.g. networking) has been their relative inaccessibility.
They're shooting themselves in the foot.

And "piracy" is utterly the wrong term.

No one (well, no one here) wants to do anything illegal, if I wanted
to do that I would have done it a long time ago.  I have both the SGML
standards and a very nice OCR thank you.  I want permission!

>Standards bodies pay a substantial portion of their administrative
>costs with the income from their sale of paper standards
>documents, in draft as well as final form.

Well, is that true? I don't know, and tend to doubt it.

There just isn't very much money in this kind of thing. As an example
I do know about, most journals, even very big/famous ones, sell
reprints at a net loss.

Do you know this, or are you guessing? (e.g. have you ever been in a
position to work with a standards body's budget?) I'd venture to guess
they make most of their money off of things like membership, workshops
(whatever they call them) and contributions or selling services.

>1) The price of the documents is far higher than the price of
>similar documents of similar publishing quality.

Low-volume/nuisance explains this. Fair enough. But selling say 100
copies/year of the SGML (e.g.) standard for $50 (about what it costs)
is hardly money (with mailing and labor it probably costs them that
much.)

I dunno, I just wonder if you do. You're appealing to "common sense"
where some info is sorely needed. Publishing, except for the big boys,
is almost always a losing business.

The only frequently updated type of paper stuff that really makes much
money (unless, as with the case of major journals, there's a big
library business for $1000/yr copies) are magazines etc which are
supported by advertising, many are mailed for free as you no doubt
know.

Note that many scholarly journals are just plain subsidized and lose
money like a sieve. ISO standards strike me as more similar to
journals than anything else (very limited audience, frequent "updates"
where updates includes new standards, drafts etc., hence low volume on
any particular print run.)

Anyhow, maybe I'm wrong. But working forward from "first principles"
is not satisfying. I am somewhat familiar with the economics of
publishing.

I admit I'm doing the same thing, but using some info to show that I
have trouble believing these claims on their face.

>And so it goes. Send them a check. By doing so, you help fund
>future standards efforts.

Which, in itself, is a questionable endeavor...:-)
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

abw@bucrsb.bu.edu (Al Wesolowsky) (09/30/90)

In article <ENAG.90Sep28195153@hild.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
+In article <1990Sep28.134332.24815@terminator.cc.umich.edu> jwh@boston.ifs.umich.edu (Jim Howe) writes:
+they do not
+even have machine-readable versions in-house, and that drafts are most
+often type-set anew for each version.  The same goes for CCITT, which
+is another paper-based standardizing body in the field of electronic
+information.  Amazing.

The cobbler's children often go barefoot...

| Al B. Wesolowsky  abw%bucrsb@bu-it.bu.edu or arc9arn@buacca.bitnet  |
|"The event you have just witnessed is based on sworn testimony. Can  |
| you prove that it didn't happen?" Criswell-_Plan 9 from Outer Space_|

hrs1@cbnewsi.att.com (herman.r.silbiger) (09/30/90)

In article <ENAG.90Sep28195153@hild.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
> In article <1990Sep28.134332.24815@terminator.cc.umich.edu> jwh@boston.ifs.umich.edu (Jim Howe) writes:
> 
>    Do you know if you can get a machine readable version of the
>    standard from ISO?
> 
> Yes, and the answer is unfortunately NO.  I learned that they do not
> even have machine-readable versions in-house, and that drafts are most
> often type-set anew for each version.  The same goes for CCITT, which
> is another paper-based standardizing body in the field of electronic
> information.  Amazing.
> 

CCITT, or rather the ITU, of which CCITT and CCIR are part, is no longer "paper
based."  All draft recommendations are produced electronically, using Microsoft
Word for Windows, and are published in-house.  Editors and contributors are
requested to submit their work in machine-readable form, and they have 
translaters for more than 20 proprietary formats.  By the end of this year
submissions can also be made in ODA conforming to the level 26 DAP (CCITT
Rec. T.505).

These documents will also be accessible electronically by Study Group members
through an interactive service called TIES.  TIES can be accessed through
modem dialup and packet networks via the Swiss PTT.  Submission can also
be via X.400 links.  The documents will be in Word format, and also ODA by
the end of the year.

CCITT is pursuing the possibility of electronic distribution, and has actually
made a Telecom directory available electronically to purchasers of the paper
version.  The electronic version is updated 4 times per year, the paper copy
yearly.  The main difficulty with electronic distribution is not technology
but obtaining payment for the information.

Herman Silbiger
hsilbiger@attmail.com

hrs1@cbnewsi.att.com (herman.r.silbiger) (09/30/90)

In article <BZS.90Sep28173259@world.std.com>, bzs@world.std.com (Barry Shein) writes:
> 
> 
> How much can they possibly be making on reprints of this stuff? This
> ain't exactly NY Times booklist stuff.
> 

The aim is not to make money, it is just to cover the cost of production and
distribution.

Herman Silbiger
hsilbiger@attmail.com

ath@prosys.se (Anders Thulin) (09/30/90)

In article <1990Sep29.021053.19864@cbnewsi.att.com> hrs1@cbnewsi.att.com (herman.r.silbiger) writes:

>Of course ODL is tied to the ODA architecture, but I don't see any reason
>why a ASN.1 version of SGML could not be done.  It might be useful to have a
>way of specifying non-hierarchical architectures in a BNF notation.

Isn't that what SDIF is about? I haven't seen the SDIF document myself,
but I have the impression that it used ASN.1 to specify a SGML interchange
format.


-- 
Anders Thulin       ath@prosys.se   {uunet,mcsun}!sunic!prosys!ath
Telesoft Europe AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/01/90)

Sigh.  Why is the truth so hard to swallow when it is inconvenient?

No, Barry, I 'm not talking from "common sense". I spent 4.5 years as a member
of ANSI X3H3, and I've gone rounds with ANSI both within and outside the
committee about cheaper access to documents. You seriously underestimate the
sales of any one standards document, and ignore the hundreds of different
documents available from each standards body. The paper documents are indeed a
good source of income, and protecting that income is the express purpose of
forbidding machine readable document formats.  We were explicitly forbidden
to disseminate or make available the working copies of our documents, and were
put to great lengths to develop an access scheme that would allow committee
members of a large committee to make changes while preventing others from
dialing up and downloading them.  This slowed down _our_ work.

I thoroughly agree with you that this impedes access to and use of the
standards, but it is still reality, and necessary lacking other sufficient
funding for the standards bodies' central administrative offices.

As for your suggestion of a "checksum" to protect document integrety, this
would prevent such little repairs as correcting spelling, and so would be
immediately ignored or replaced as the document is updated.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

bzs@world.std.com (Barry Shein) (10/01/90)

>> How much can they possibly be making on reprints of this stuff? This
>> ain't exactly NY Times booklist stuff.
>> 
>
>The aim is not to make money, it is just to cover the cost of production and
>distribution.
>
>Herman Silbiger

I did not mean to imply that they were profitting off this activity
(or, better put, "I did not mean to imply that they were not
profitting..."), I was asking whether they really could be covering
any significant costs in this manner. I suppose one could always argue
that they're at least losing less.

But simply producing and shipping paper copies tends to have a high
overhead, particularly the labor involved (it takes real staff to
track something down, make copies, pack, mail etc.) It's not hard to
come out net negative merely on the activity of selling copies of
documents. Or, perhaps, only cover the cost of distributing the copies.

If that's the case, then why not just distribute it electronically and
get rid of most of the overhead?

And electronic copies don't eliminate sales, they might drive them in
other directions. For example, Unix manuals have been on-line since
the beginning of Unix, yet I don't think anyone doubts there's a brisk
business in paper Unix documentation.

USENIX alone has sold, I dunno, hundreds if not thousands of BSD Unix
manuals (basically just hard copy of what's on-line) over the years,
mostly to people who also had access to exactly the same thing
on-line.

It's not an either/or proposition. What happens is that availability
of the documents on-line gets people using the information, exploring
it.

It widens the audience vastly when, eg, every CS dept has an
electronic copy of (say) OSI docs. Right now I bet very few people in
CS depts in the US have ever even seen one of these documents, let
alone come to depend on them as a reference base. I know in the 10
years I spent at Boston University I never saw one around. What I have
I had to hunt down and order (and yes, had to work hard to learn what
to even ask for!)

I think the standards organizations are being foolish on this point.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

bzs@world.std.com (Barry Shein) (10/01/90)

>As for your suggestion of a "checksum" to protect document integrety, this
>would prevent such little repairs as correcting spelling, and so would be
>immediately ignored or replaced as the document is updated.
>
>Kent, the man from xanth.

Again, you're tossing the whole idea of on-line documentation in the
trash. So we need a different solution.

Nelson in Literary Machines discusses this. He basically comes up with
a scheme very similar to SCCS or RCS, using versioning and difference
files.

Just another example of a possible solution.

I honestly don't think this is a huge problem or proves anything. As I
said, how often do you use the "man" command on Unix and say "hmm,
it's possible someone tampered with this..." Go cut the tamperer's
hands off or get a reliable, private copy.

But it's not the critical issue in this.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

enag@ifi.uio.no (Erik Naggum) (10/01/90)

In article <ENAG.90Sep28195153@hild.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
 
> Yes, and the answer is unfortunately NO.  I learned that they do not
> even have machine-readable versions in-house, and that drafts are most
> often type-set anew for each version.  The same goes for CCITT, which
> is another paper-based standardizing body in the field of electronic
> information.  Amazing.

In article <1990Sep30.023741.9306@cbnewsi.att.com> hrs1@cbnewsi.att.com (herman.r.silbiger) writes:

> CCITT, or rather the ITU, of which CCITT and CCIR are part, is no
> longer "paper based."  All draft recommendations are produced
> electronically, using Microsoft Word for Windows, and are published
> in-house.  Editors and contributors are requested to submit their
> work in machine-readable form, and they have translaters for more
> than 20 proprietary formats.  By the end of this year submissions
> can also be made in ODA conforming to the level 26 DAP (CCITT Rec.
> T.505).

> These documents will also be accessible electronically by Study
> Group members through an interactive service called TIES.  TIES can
> be accessed through modem dialup and packet networks via the Swiss
> PTT.  Submission can also be via X.400 links.  The documents will be
> in Word format, and also ODA by the end of the year.

> CCITT is pursuing the possibility of electronic distribution, and
> has actually made a Telecom directory available electronically to
> purchasers of the paper version.  The electronic version is updated
> 4 times per year, the paper copy yearly.  The main difficulty with
> electronic distribution is not technology but obtaining payment for
> the information.

I'm confused.  Wednesday September 26th 1990, I attended a seminar
held at the Telco Research facility at Kjeller outside Oslo, chaired
by Bente Manns&aring;ker, who is the Norwegian Telco's representative
at SG VII (X. series, if VII is wrong -- it might be).  I asked her in
the Q&A period after her lecture whether CCITT used electronic or
paper documents for internal work, and she replied paper documents.
Not entirely happy with the answer, I approached her in the break, and
asked if CCITT disseminated drafts electronically to their members,
and whether drafts existed in some electronic form, available to the
respective Working Parties, etc, in general whether the process was
electronic or paper-based.  Again, she replied that everything was
essentially paper-based, but that individual WP members often had
contributions on "some PC format" diskettes.  She was not aware of any
common format or attempts to define such.

Now, who should I trust?  I got to know Manns&aring;ker a little, and
got the feel that she may not know the details of the work she is
dealing with, but that she does a very good job for the people in the
Working Parties and other researchers back here that she is
representing.  We discussed the new X.25 A-bit (for Type-Of-Address/
Numbering Plan Indicator (TOA/NPI)) and its implication for the
address block format, including a weak expression of intent in section
5.2.1.2.1/X.25 and lack of correspondance with Figure 5/X.25, which is
identical to Figure 4/X.25.  (Thanks to Kent England for pointing this
out to me, and giving me the chance to pursue this point.)

It was in reference to this seminar and this person that I said what I
said above.  If this is wrong, I may of course again be able to
impress her by knowing more about her work than she herself does...

However, she did say that the mass of paper that she received prior to
each SG VII meeting weighed fully 8 kg (~16#).  I would surmise that a
2400' tape would be a little easier to distribute, if they could.

I hope to get some more information on this, and I will most certainly
pursue it.

-----

As Barry Shein has mentioned repeatedly (I got the point the first
time ;-), paper copies complement electronic copies, they are not
inferior to them, and would not go away.  I have paper copies of all
the relevant RFC's for my work and interest, and I would happily pay
for them if that could further the good work done.  Laser printers may
be good enough for a lot of things, but real type-set paper copies,
nicely bound, would perhaps make the standards themselves a little
more "prestigeous."

Likewise, I have bought the ODA and SGML standards, as well as 1.8
shelf-feet of the CCITT Blue Book, but would _so_ like to "grep" for
some keyword, which I'm so used to with the Internet stuff.  Nothing
compares to books by the bedside, and for real studying, electronic
copies just don't do it.  (At least not for me; am I getting old at
young age? :-)

-----

Sorry for the use of "&aring;" in her name, but I guess you all know
how it looks when thus represented.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427

ath@prosys.se (Anders Thulin) (10/01/90)

In article <BZS.90Sep30142336@world.std.com> bzs@world.std.com (Barry Shein) writes:
>
>If that's the case, then why not just distribute it electronically and
>get rid of most of the overhead?
> [ ... ]
>
>I think the standards organizations are being foolish on this point.

Isn't IEEE doing some useful work here? I saw somewhere that they
planned to maked the POSIX documents available on CD-ROM, and if
things went well, go on with other IEEE standards. Can anyone confirm
this?

Indeed, CD-ROM seems to be a reasonable compromise: the standards
organization can recoup their costs, and the user can (hopefully)
'use' the texts, not only read them. And if a dispute as to tampering
arises, there is always the original CD to settle the point.

-- 
Anders Thulin       ath@prosys.se   {uunet,mcsun}!sunic!prosys!ath
Telesoft Europe AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

koushik@isrmac1.cs.vt.edu (Prabhakar M. Koushik) (10/02/90)

In article <BZS.90Sep30142336@world.std.com> bzs@world.std.com (Barry Shein) writes:
>It widens the audience vastly when, eg, every CS dept has an
>electronic copy of (say) OSI docs. Right now I bet very few people in
>CS depts in the US have ever even seen one of these documents, let
>alone come to depend on them as a reference base. I know in the 10
>years I spent at Boston University I never saw one around. What I have
>I had to hunt down and order (and yes, had to work hard to learn what
>to even ask for!)

I think Barry's point is well taken. Anyhing I would have to say on this
would be an exact echo. It is not by making things inaccessible that you
can drive up its popularity/audience. While the issue of cost recovery
etc. cannot be ignored, it shouldn't be the primary deterrent.
-Koushik 

-------------------------------------------------------------------------
std. discalimers apply.  e-mail to koushik@vtodie.cs.vt.edu
-------------------------------------------------------------------------

hrs1@cbnewsi.att.com (herman.r.silbiger) (10/02/90)

In article <ENAG.90Oct1015128@hild.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
> In article <1990Sep30.023741.9306@cbnewsi.att.com> hrs1@cbnewsi.att.com (herman.r.silbiger) writes:
> 
> > CCITT, or rather the ITU, of which CCITT and CCIR are part, is no
> > longer "paper based."  All draft recommendations are produced
> > electronically, using Microsoft Word for Windows, and are published
> > in-house.  Editors and contributors are requested to submit their
> > work in machine-readable form, and they have translaters for more
> > than 20 proprietary formats.  By the end of this year submissions
> > can also be made in ODA conforming to the level 26 DAP (CCITT Rec.
> > T.505).
> 
> > These documents will also be accessible electronically by Study
> > Group members through an interactive service called TIES.  TIES can
> > be accessed through modem dialup and packet networks via the Swiss
> > PTT.  Submission can also be via X.400 links.  The documents will be
> > in Word format, and also ODA by the end of the year.
> 
> > CCITT is pursuing the possibility of electronic distribution, and
> > has actually made a Telecom directory available electronically to
> > purchasers of the paper version.  The electronic version is updated
> > 4 times per year, the paper copy yearly.  The main difficulty with
> > electronic distribution is not technology but obtaining payment for
> > the information.
> 
> I'm confused.  Wednesday September 26th 1990, I attended a seminar
> held at the Telco Research facility at Kjeller outside Oslo, chaired
> by Bente Manns&aring;ker, who is the Norwegian Telco's representative
> at SG VII (X. series, if VII is wrong -- it might be).  I asked her in
> the Q&A period after her lecture whether CCITT used electronic or
> paper documents for internal work, and she replied paper documents.
> Not entirely happy with the answer, I approached her in the break, and
> asked if CCITT disseminated drafts electronically to their members,
> and whether drafts existed in some electronic form, available to the
> respective Working Parties, etc, in general whether the process was
> electronic or paper-based.  Again, she replied that everything was
> essentially paper-based, but that individual WP members often had
> contributions on "some PC format" diskettes.  She was not aware of any
> common format or attempts to define such.
> 
> Now, who should I trust?  I got to know Manns&aring;ker a little, and
> got the feel that she may not know the details of the work she is
> dealing with, but that she does a very good job for the people in the
> Working Parties and other researchers back here that she is
> representing.  We discussed the new X.25 A-bit (for Type-Of-Address/
> Numbering Plan Indicator (TOA/NPI)) and its implication for the
> address block format, including a weak expression of intent in section
> 5.2.1.2.1/X.25 and lack of correspondance with Figure 5/X.25, which is
> identical to Figure 4/X.25.  (Thanks to Kent England for pointing this
> out to me, and giving me the chance to pursue this point.)

Starting this year, the staff of the ITU computing center has been giving
seminars at Study Group meetings describing the electronic document
creation, publishing, and database system.   All members have been invited to
participate.  It is true that this project is just starting, but all the
capabilities I described are in place.  I, and several others I know, have
a login on the TIES system.   While the electronic submission of documents may
be slow to get started, the publishing part is in operation.  General electronic
distribution may be some time in coming, like in the rest of the world, most
participants are not yet equipped to participate in this.

When I was in Geneva 2 weeks ago, I obtained a copy of the template used for
CCITT Recommendations.  I am planning to use it in my next contribution to
Study Group VIII.

One thing that I did not mention in my previous reply is the difference in
approach by the ITU and ISO.  The ITU has a distributed system, with PCs on
LANs and servers.  ISO is installing an IBM mainframe to handle their (SGML-
based) publishing.  ISO has, however, agreed to use MS Word for Windows as
their basic word processor, to enable files for common standards to be
interchanged at that level.  ISO's publishing is based on a very large DTD
which they wrote.

Herman Silbiger
Chairman CCITT Study Group VIII Working Party 4 - Document Architecture
hsilbiger@attmail.com

tim@maths.tcd.ie (Timothy Murphy) (10/03/90)

In <1990Sep30.191643.13942@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:

>The paper documents are indeed a
>good source of income, and protecting that income is the express purpose of
>forbidding machine readable document formats.  

Why not auction the standard?
Sotheby's would do a great job,
with a nubile lady holding up the latest version of SGML.

-- 

Timothy Murphy  

e-mail: tim@maths.tcd.ie

hrs1@cbnewsi.att.com (herman.r.silbiger) (10/05/90)

In article <609@juno.prosys.se>, ath@prosys.se (Anders Thulin) writes:
> 
> Isn't that what SDIF is about? I haven't seen the SDIF document myself,
> but I have the impression that it used ASN.1 to specify a SGML interchange
> format.
> 
SDIF provides an ASN.1 envelope for an SGML encoded document, to enable it to be
interchanged in an ASN.1 environment.  The document is still "normal" SGML.

Herman Silbiger
hsilbiger@att.com

Markku.Savela@tel.vtt.fi (Markku Savela) (10/06/90)

In article <1990Oct5.002410.3924@cbnewsi.att.com> hrs1@cbnewsi.att.com (herman.r.silbiger) writes:
>SDIF provides an ASN.1 envelope for an SGML encoded document, to enable it to be

  I have always thought that SDIF was a presentation of ODA
structure in with SGML, a DTD matching ODA structures (e.g.
nothing to do with ASN.1).
--
Markku Savela                         | savela@tel.vtt.fi
Technical Research Centre of Finland  |
Telecommunications Laboratory         | Markku.Savela@vtt.fi
Otakaari 7 B, SF-02150 ESPOO, Finland | savela%vtttel@router.funet.fi 

enag@ifi.uio.no (Erik Naggum) (10/07/90)

In article <5166@hemuli.tik.vtt.fi> Markku.Savela@tel.vtt.fi (Markku Savela) writes:

     I have always thought that SDIF was a presentation of ODA
   structure in with SGML, a DTD matching ODA structures (e.g.
   nothing to do with ASN.1).

You're probably thinking of ODL (Office Document Language), which
makes ODA an SGML application, then uses SDIF to encode it.
(As far as I got it.  Correction solicited.)

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427

Markku.Savela@tel.vtt.fi (Markku Savela) (10/08/90)

In article <ENAG.90Oct6195312@hild.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
>You're probably thinking of ODL (Office Document Language), which

   Yes, now that I checked it, you are right, Silbiger is right
{ I should have known better, than rely on my memory. :-}

--
Markku Savela                         | savela@tel.vtt.fi
Technical Research Centre of Finland  |
Telecommunications Laboratory         | Markku.Savela@vtt.fi
Otakaari 7 B, SF-02150 ESPOO, Finland | savela%vtttel@router.funet.fi 

yuri@sqzme.sq.com (Yuri Rubinsky) (10/11/90)

In article <1990Oct5.002410.3924@cbnewsi.att.com>
hrs1@cbnewsi.att.com (herman.r.silbiger) writes:

>SDIF provides an ASN.1 envelope for an SGML encoded document,

In article <5166@hemuli.tik.vtt.fi>
Markku.Savela@tel.vtt.fi (Markku Savela) writes:

>   I have always thought that SDIF was a presentation of ODA
> structure in with SGML, a DTD matching ODA structures (e.g.
> nothing to do with ASN.1).

at which point

enag@ifi.uio.no (Erik Naggum) writes:

> You're probably thinking of ODL (Office Document Language), which
> makes ODA an SGML application, then uses SDIF to encode it.
> (As far as I got it.  Correction solicited.)

Erik and Herman are both right, and indeed, Markku later re-posted
explaining he had found the explanation. Nonetheless, I'm taking the
liberty of posting a slightly more detailed description of some of
the finer points. (This may be construed as the correction that Erik
solicited.)

SDIF can and does provide an ASN.1 envelope for an SGML encoded document,
and is generally assumed to do so, although strictly speaking,
one could use other methods for the interchange.


ISO 9069 (SDIF) defines the SGML Document Interchange Format as:
"A data structure that enables a main document and its related documents,
each of which may be stored in several entities, to be combined into a
single data stream for interchange in a manner that will permit the
recipient to reconstitute the separate entities."

That's it. Nothing about ODL or ODA or even ASN.1.

An ODA document, encoded in ODL, may, **like any other SGML document**
be enveloped in an SDIF data stream. ODL contents, like SGML documents
from any other application, may be "packed" in SDIF.


ISO 9069 formally defines SDIF in the abstract, and uses
ASN.1 as the grammar for the abstract definition. As Charles 
Goldfarb says in The SGML Handbook (available within a
few weeks, I understand), "A specific encoding
for SDIF (as, indeed, for any structure defined in ASN.1) can be
derived automatically from the abstract syntax by applying the
ASN.1 basic encoding rules, defined in ISO 8825. It is expected
that SDIF data streams in Open Systems Interconnection (OSI)
environments will be encoded in this way. However, the standard
allows any encoding accepted by the medium of interchange."

Goldfarb then goes on to explain how SGML documents in SDIF can
be interchanged with the FTAM (ISO 8571), JTM (ISO 8832) and
MHS or X.400 protocols, and using the MOTIS functions defined in
ISO 8505 and 8883.


The most valuable feature of this interchange is that it can include
the logical and layout structures within ODA and still take advantage
of SGML's entity structure: This allows users critical flexibility:
SGML documents may exist in any number of files on a system, separated
as to content notation (graphic formats, for example) or
as chapters in a book, or whatever. SDIF
"packs" them together and provides for full "unpacking" to recreate
that entity structure.

----------------------------------------------------------------
Yuri Rubinsky				(416) 963-8337
President                               (800) 387-2777 (from U.S. only)
SoftQuad Inc.				uucp: {uunet,utzoo}!sq!yuri
720 Spadina Ave.			Internet: yuri@sq.com
Toronto, Ontario, Canada M5S 2T9	Fax: (416) 963-9575