>>How about <em h1>? The semantic meaning is: "This is a header where it should
>>not appear".
>
> Why not just <f1> ?

Because <f1> is similar to <b>, <i>, whose use should be discouraged. <em>
tag is the one that should be used for rendering hints.

Aleks

> How about <em h1>? The semantic meaning is: "This is a header where it should
> not appear".

Why not just <f1> ?

-Crh

     Charles Henrich     Michigan State University     henrich@...

                      http://rs560.msu.edu/~henrich/

> > Why not just <f1> ?
>
> Because <f1> is similar to <b>, <i>, whose use should be discouraged. <em>
> tag is the one that should be used for rendering hints.

Ah Thats where I disagree.  Overloading the <em> tag excessivly is a bad idea,
which has at some point been agreed to on the list, when the initial HTML+ spec
used <em bold> instead of <b>.   Explicit tags are not a bad thing IMHO.

-Crh

     Charles Henrich     Michigan State University     henrich@...

                      http://rs560.msu.edu/~henrich/

>We will be better served in the long run if we do not base our
>designs on the current implementation of AFS or for that matter Unix.
>Clock cycles get cheaper every day, but every kludgy feature you
>add is paid for in human labor, which grows ever more expensive.

Not all of us accept the arguments of some of you that the elegance
of hiding the fact that a URL is a script is a Good Thing.  I
continue to believe that the idea of having script authors identify
scripts versus files by what directory the files reside in, or
the execute bit, or something in the server config file is far
from the best solution.  I believe the .CGI suffix (or even better
.EXEC or .SCRIPT) -- ie explicit naming of scripts -- is the way
to go.

This notion that it's important to be able to replace files with
scripts without changing file names is only one argument.  I think
if you want the masses to be able to write HTML and share HTML
documents from server to server it's better if scripts are
flagged explicitly, not by some server-dependent "out-of-band"
notation.



/Rich Wiggins, CWIS Coordinator, Michigan State U

In reviewing the HTML design, try to keep in mind folks with an audio
interface, who expect the document to be read to them. There are lots
of ways to render a heading or a title in spoken language, and even a
way to render 'emphasis', and even varying degrees of emphasis.
However, it's very hard to render 'bold'.

Even if this would be overloading <em *>, doing so would be
significantly better than using <h*>s -- using <h*>s to express font
size would be a real departure from their intended use.

HTML is (fortunately or unfortunately) a document type of SGML, which
defines document content, not document formatting.  IMHO, it is the
responsibility of browser writers to supply adequate options for handling
whitespace.  If HTML is extended to include formatting information, it
becomes YAWPF (Yet Another Word Processing Format :), unsuitable for users
who do not possess (or could not use) GUI browsers.
======================================================================
Mark Fisher                            Thomson Consumer Electronics
fisherm@...           Indianapolis, IN

"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."

So long as we're exchanging proposals for how servers might more flexibly
find CGI scripts, here's what I've done to my server.  More or less the
same thing is available in HTML as

   http://www.ai.mit.edu/xperimental/run-scripts.html

That file also contains a pointer to the code which implements all this, as
a patch to NCSA httpd 1.0.  I'm also forwarding some comments on Rich
Brandwein's proposal (which seems to me to be basically in the same spirit)
under separate cover.

The RunScripts option

I've implemented a new option, RunScripts, to the Allow directive of
access.conf and .htaccess files. This option allows the server maintainer
to designate certain directories as containing both scripts and ordinary
files, and to have the server be able to retrieve both from those (and only
those) directories.

What it does

The RunScripts option allows scripts to be run from any directory where the
server might find ordinary files, whether those directories are
subdirectories of SERVER_ROOT, a user's public_html area, an Aliased
directory, or whatever, so long as RunScripts is enabled for the directory
in question. It may be enabled (or disabled) for a particular directory and
its subdirectories via Options directives in access.conf in the usual way,
and overrides via .htaccess files may likewise be permitted or disallowed
as usual.

(In fact, you will have to edit these files to tell the daemon which
directories you want RunScripts to apply to, unless they already say
Options All).

Having scripts and ordinary files in the same directory raises the question
of how to tell which is which. That's resolved by a naming convention, as
follows:

If a file named .../some_dir/foo.doit or .../some_dir/foo.nph is placed in
a directory .../some_dir which has RunScripts enabled, the server will
attempt to run it as a CGI script to handle HTTP GETs and POSTs to URLs of
the form:

    *) .../some_dir/foo/bar/zot
    *) .../some_dir/foo?some+query+args
    *) HTTP POSTs to .../some_dir/foo
    *) HTTP GETs to .../some_dir/foo unless an actual file named
       .../some_dir/foo is sitting in the file system alongside
       .../some_dir/foo.doit.

       If such a file does exist, it will be retrieved for parameterless
       GETs, and the script will not be invoked. This allows 'coversheets'
       for ISINDEX documents to be put in a separate file, which is an
       occasional minor convenience.

Giving a script the .nph extension instead of .doit has exactly the same
effect as making its name start with nph-, namely, that it has complete
control of the connection back to the client, and is therefore required to
generate all relevant HTTP and MIME headers. The only functional difference
between supplying nph as a prefix vs. as an extension is that in the latter
case, implementation details of the script aren't wired into the URL.

Note also that the .doit and .nph extensions are *not* visible to clients.
This is so that pre-existing files and directories can be turned into
scripts, and vice versa, without changing all references to them as well.

One last special case --- .doit and .nph files cannot be retrieved
directly. That is, an attempt to retrieve .../some_dir/foo.doit will fail
even if the file does exist, and an attempt to retrieve .../some_dir/foo
would invoke it as a script. Attempts to retrieve Emacs backup or auto-save
files (i.e., those ending in '~' or '#') will likewise fail, and all of
these files are left out of automatically-generated directory lists. This
is an attempt on my part to make sure people don't export code without
knowing it, which can be a potential security risk.

Compatibility with existing stuff

The RunScripts patch has no effect on the behavior of ScriptAlias at all.
This means that a ScriptAlias to some directory and an Alias to the same
directory have different effects, even if that directory has RunScripts
enabled. Different naming conventions are in effect (when looking for
scripts in ScriptAliased space, the server does not use the .doit or .nph
suffixes), attempts to retrieve ordinary files from ScriptAliased space
will fail, and of course, the RunScripts option is not required to run
scripts from a URL covered by a ScriptAlias.

There are two known incompatibilities, both minor (at least as I see them):

*) Options All means something different with the patch installed, since
    All includes RunScripts.

    The only way to do this back-compatibly is to have multiple levels of
    all-inclusive keywords --- as on certain Unices, in which stty all shows
    every tty mode setting you ever heard of, while stty everything shows
    you the rest of them.

*) The prohibitions on retrieval of certain files apply even in directories
    where RunScripts is off. The intention here is that if some malign
    influence arranges for a .htaccess file to appear in some directory
    which says Options Indexes, they don't then get to cruise the scripts in
    that directory for something useful while waiting for the site
    maintainer to remove the thing.

If people would like to play around with this, and don't mind experimenting
with unsupported software, then the code is available --- see the URL above.

rst

From: rhb@...
    Date: Sun, 9 Jan 94 20:04:00 EST

[ Back from the NSF site visit... ]  Here are a few gut-level responses to
Rich's proposal.  I've posted what amounts to a proposal of my own, in the
form of the documentation for the changes I've made to the server, which
I'll forward along under separate cover.  Here's some comparison between
mine and Rich's...

    Based on some limited discussion here, I propose the following:

    Add to the srm.conf file:
    ***************************

    # UserExec: Whether local user executables is activated
    #

    UserExec True
    ***************************

    Add a .srm_conf file in the users public_html directory
    (or whatever it's set to in the server's srm.conf file)
    ***************************

    # ScriptAlias: This controls which directories contain server scripts.
    # Format: ScriptAlias fakename realname

    ScriptAlias /cgi-bin /home/rhb/myscripts

The net effect of this, if I understand it right, would be to designate
certain directories as all-script and others as all-file.  It may be
simpler to just add an Allow attribute to the .htaccess files, so that a
.htaccess file with "Allow Scripts" in it would enable execution of scripts
from the directory containing it, and any subdirectories.  This also would
ease the load on the server a bit --- it's looking for .htaccess files
anyway, while it is not yet looking for .srm_confs as well.  Then again,
I'm biased ;-).

At any rate, that's why I added the attribute to the .htaccess files,
rather than adding code for an entirely new config file.

    #and possibly a line that includes info on how I identify
    #my executable files

    ExecAlias magic, suffix=exe
    ***************************

    One point brought to my attention is that all directories are already
    "executable" in the NCSA server environment via the <inc var> directive
    (i.e., this takes care of my original problem of getting to the
    user variable in authentication), but it doesn't take care of things
    like forms.

    Now a more general question that turns the previous question inside
    out.  The original concern was in adding executables to directories
    that were not indicated as having executables.  Well it seems that
    I can certainly have "regular" (non script) html files in executable
    directories.  What do I gain from having a directory "not executable"?
    Why aren't all directories cgi-bin directories?  I can restrict
    GET in the directories in which I really have scripts if I'm concerned
    about reading scripts...

In fact, that's basically the situation that I've got here --- all
directories are, at least potentially, cgi-bin directories (modulo the
trivia which I discuss under "compatibility").

Briefly, what you might gain from having a directory "not-executable" is
that if the directory is controlled by people you don't trust, they can't
screw you over as much.  Universities with a large population of
potentially hostile undergraduates are the classic example.  This is why
the NCSA server allows the adminstrator to control use of server scripts,
for instance, which (as you point out) raise many of the same security
issues.

    This in fact points up the need to have a "smart" server.  It is important
    that the server be able to identify the files it's serving not just by their
    suffix (i.e., in the mime type file) but via any available attribute
    (such as magic numbers).  The information that's available differs
    among platforms and application (server) needs.  I'm in agreement that
    we need a flexible method that allows the server to use it's "smarts"
    and the users' needs (e.g., the scripts I am interested in providing
    are all perl and tcl, so the #! would work for my application...).

It's certainly true that in the best of all possible worlds,
metainformation such as script-ness and MIME type would be represented
explicitly.  Gopher servers do this, for instance --- and explicitly
maintaining all the metainformation, and keeping it in synch with the files
themselves, turns out to be something of a chore.  The trick is to come up
with a scheme which is as simple and maintainable as the hack of
overloading this information onto file names (which is admittedly ugly, but
time-honored --- going back to 1963 at least).

    Rich

rst

Dudu Rashty writes:

> EARN Guide to Network Resources Tools Ver 2.0 is available from
> http://vms.huji.ac.il/WWW_HELP/earn.html

Can anyone get to this?  I get a "Requested document ... could not
be accessed ..."

Steve.

=====================================================================
Stephen C. Waterbury  Phone: 301-286-7557
NASA Parts Project Office FAX: 301-286-1695
Code 310.A 	 email: waterbug@...
NASA/GSFC 	 "Sometimes you're the windshield;
Greenbelt, MD 20771 	 sometimes you're the bug."
=====================================================================

> Dave Ragget writes:
>> The latest ideas for forms include a new STATE element that
>> allows servers to store information in forms in a manner
>> that is opaque to browsers.

> This is *exactly* the element I'm looking for.  Any status on
> where it stands?

It's in the new DTD for HTML+ I recently mailed out. You can get
another copy from ftp://15.254.100.100/pub/htmlplus.dtd.txt

The idea originated in a phone call with Tim Berners-Lee and
I have yet to write it up formally. I hope to make the next
draft of the HTML+ spec available via the Web rather than as
a large postscipt file and expect to complete this write up
by mid-February.

Dave

Somewhat late, I know, but you can now read the minutes of the
WWW/TEI meeting held last November in Cork, Ireland. This
proved a very valuable occasion, bringing together browser writers
with members of the SGML community.

         ftp://15.254.100.100/pub/cork_tei_www.html

My thanks to Lou Burnard for his permission to publish his
notes on the meeting.

Dave Raggett

p.s. I would be very grateful if someone would volounteer to move
the report to a more permanent home than our anonymous ftp server.

When creating a new www "service", it can be useful to reflect the
service name in the "path", in addition to reflecting it, as is
customary, in the DNS "host"name.

Suppose you are announcing a new www service, which is running on a
machine mydesk.cs.nowhere.edu .  People used to announce the service as
http://mydesk.cs.nowhere.edu/ .

This has the recognized problem that you may someday wish to use a
different machine.  So the convention has developed of creating a DNS
alias or pointer.  Thus you might announce http://www.cs.nowhere.edu/ .

But a related problem is NOT addressed by this solution:
   It is not posible to transparently move two services,
   begun on different servers, to a single server.

For service identity is being uniquely determined by the DNS name,
as a server receiving a connection does not know the name(s) which
the client resolved to find the server's IP address.

Adding service identity to the "path" addresses this problem.
One might announce  http://www.cs.nowhere.edu/www-cs/ .
This allows you to later, transparently, let the server providing
http://www.nowhere.edu/nowhere/ to also provide your service.
And lets you run take over the experimental
http://mumble-www.cs.nowhere.edu/mumble/ .

Mitchell

Dave Raggett wrote:

>> Larry Masinter writes:

> In reviewing the HTML design, try to keep in mind folks with an audio
> interface, who expect the document to be read to them. There are lots
> of ways to render a heading or a title in spoken language, and even a
> way to render 'emphasis', and even varying degrees of emphasis.
> However, it's very hard to render 'bold'.

Good point! (In my office is a blind programmer, believe it or not)

>> In using emphasis authors would like to be sure that a given set of
>> emphasis tags will in fact be rendered differently on *ALL* browsers.
>> The precise way these are differentiated will clearly depend on the
>> characteristics of each browser, on dumb terminals email conventions
>> could be used while on others color and font attributes can be used.

Very true.

>> Now, while we could use neutral names such as <HP0> <HP1> ... <HP4>
>> most of us would prefer more meaningful names which convey the common
>> interpretation. This explains why <B>, <I> etc are well liked.

>> The problem with "logical" emphasis tags is there is no easy way of
                                                ^^^^^^^^^^^^^^^^^^^^^^^
>> pulling together an effective small set. In my attempts to do so for
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
maybe there is....

>> HTML+, it rapidly became apparent that this is a bottomless pit.
>> The set in the DTD provides just a few extras to those in HTML, perhaps
>> leaning too far towards the needs of computer manuals. As for <EM> and
>> <STRONG> these are ok for some purposes, but comprise too small a set.

>> Dave Raggett

All very good points, and I have hit this wall several times (ie: I
have many different 'logical' types of text), and ask myself such
questions as 'do I use <CODE> or <KBD> or <SAMP> to tag a directory
name', and so on.  I am *eagerly* awaiting support for <RENDER ...> so
that I can preface my documents with <RENDER DIR KBD> (or whatever the
syntax; I don't have my HTML+ spec handy).

Does it not make sense to remove all of the physical styles (bold,
italic, underline, etc.) in favor of the logical (emphasis, strong,
etc.) since each author can use <RENDER> to make a HTML+ compliant
document using any tags that seem appropriate?  In some respects I
think the generic names would be fine for the following proposal,
though I use <EM> and <STRONG> whenever possible.

Now, I know some folks will say "but I want this word ITALIC,
dagnabbit!".  I firmly believe that the 'spirit' of HTML is that we
are free from having to make such decisions.

My suggestion is perhaps to have a <FACE> tag (or maybe <HINT> or
<STYLE>, but I'll use <FACE> for this discussion) which more-or-less
says "If at all possible, render <TAG> as 'style' (eg: <FACE EM
'italic'> would mean: if at all possible, render '<EM>' in an italic
style.  The first argument (?) to FACE would be a valid tag such as
EM, STRONG, KBD, etc.  The second argument would be a fixed set
of styles such as 'italic', 'bold', 'bold-italic', 'reverse', which
could be combined into 'faces' (ala emacs).  Unlike RENDER, which is
effectively a preprocessor statement, <FACE> would speak directly to
the browser, expressing the wishes of the author.  One could then do
something like (forgive syntactical errors):

<RENDER FILENAME KBD>    <!-- render <FILENAME> like <KBD>      -->
<RENDER DIRNAME  KBD>    <!-- ditto for <DIRNAME>               -->
<FACE KBD 'fixed-bold'>  <!-- suggest that <KBD> be rendered as -->
                          <!-- fixed-width characters, bolded    -->

<H2>Typographic conventions</H2
The following typographic conventions are used in this document:<BR>
filenames are shown in <FILENAME>this font</FILENAME> (typically
bolded fixed width characters)<BR>
directory names are shown in <DIRNAME>this font</DIRNAME>... <BR>

... etc. and so on ad infinitum ad nauseum...

With this, authors are free to choose the emphasis styles that best
meet their needs for a given document, and HTML+ is not riddled with
100's of emphasis styles.  Those that want to use <I> and <B> are
happy without having <I> and <B> officially part of the spec, and the
browsers can attempt to render the way the author intended.

Comments?

---------------------------------------------------------------------
Instrument Approach Procedures Automation             DOT/FAA/AMI-230
---------------------------------------------------------------------
Bryan D. Oakley              ctrbdo%iapa@...
KENROB and Associates, Inc.              voice: (405) 954-7176 (work)
5909 NW Expwy Suite 209                         (405) 366-6248 (home)
Oklahoma City, Ok.  73132

/*
  * Re: HomePage URL without a file name.How?  by dolesa@...
(dolesa@...)
  *    written on Jan  6,  5:43pm.
  *
  *
  *
  * It took me a while to figure that one out too.  Index.html is the default
  * name.  If you don't have a document named that, it will create a directory
  * index for you, thus bypassing your intended home page.  This is not
  * documented very clearly.  Hope this helps.
  *
  */

Actually, I created the document
http://hoohoo.ncsa.uiuc.edu/docs/setup/admin/AccessingFiles.html because I
was recieving nine million questions exactly like that... I'm not sure how
much more clearly I can document it.

--Rob

Jim McBeath wrote:
> "PathNext" and "PathPrevious" buttons would facilitate stepping forwards
> and backwards through the nodes of the currently active path.

Two suggestions:

*** Next and Previous Buttons ***

I would like to see WWW browsers (especially Mosaic) implement "Next"
and "Previous" as they are in the original CERN line mode browser.
That way, any HTML document with a list of links in it can be used to
traverse a "PATH".

*** Display Selected Documents in a *Fixed* Second Viewer ***

A related feature I would like to see in Mosaic is this (inspired by a
feature in the original Viola browser):

Currently middle button selections (in X Mosaic) always spawn a new
document view window.  I would much rather it only create a new window
the first time, and then reuse that viewer for subsequent middle button
selections.  (The "Clone" button can always be used to open additional
viewers).


These changes are even simpler than the proposed PATH features
(although some of those would be nice also).

Comments?

Steve Putz Xerox Palo Alto Research Center

> Some quick questions on the authentication mechanism, at least as
> implemented in Mosaic 2.x.  I can't seem to find any specific
> documentation on this subject.

Mosaic uses libwww authentication code, documented in

	 http://info.cern.ch/hypertext/WWW/AccessAuthorization/Overview.html

What you need to read is the page:

	 http://info.cern.ch/hypertext/WWW/AccessAuthorization/Browser.html


> Does Mosaic 2.x ever stop sending the authentication fields
> to a server,  i.e., is the only way to ensure that a session
> is closed to close the window?

For that server to directories that are protected -- no, it won't
stop.  AA info is only lost when exiting Mosaic, otherwise it's
cached globally (so exiting one window won't lose it -- this is
how it was designed to work, to minimize the amount of wasted time
in typing in usernames and passwords).

Important note: username and password for a given server are NEVER
sent to any other server, so you don't need to worry about your
authentication info going to vicious servers and their maintainers.


> Secondly, how many different servers can Mosaic 2.x authenticate
> to within the same window/process?  Is it greater than 1?

Unlimited number of servers/process.  Windows have nothing to do
with authentication.

-- Cheers, Ari --

I am looking for some postscript files that I once had and hope some
kind soul can help me acquire them.  I have been 'volunteered' to demo
what we've done with HTML to a group who is tasked to develop a
monolithic system for distributing and maintaining documents (for a
major US government 8^|).  They seemed interested in what the WWW is all
about, but skeptical at it's newness (and cheapness).

When I first investigated what WWW was all about I had found some nice
postscript documents which I would like to give to the demo-ees.
Problem is, I don't have the files anymore, I don't know where I got
them in the first place, and I don't have an internet connection so I
can't easily get them (yeah, I know, but Mosaic works great for LANs
too).

I am hoping that if you know of, or possess, some of the documents I
am looking for we can arrange for you to email them to me.  Sadly, I
need them Real Soon (tm) (Jan 13th).  The documents I am looking for
are described below.  In all cases I have probably-old hardcopy from
the original postscript document (as opposed to a printed HTML file),
and am looking to obtain the most recent version of the original
postscript source.

1) 'NCSA Mosaic Technical Summary'.  This is a nice paper written by
Marc Andreessen on what the NCSA Mosaic product is all about.  The
version I have is dated February 20, 1993.

2) 'Getting Started with NCSA Mosaic'.  Again written by Marc
Andreessen, this details what is needed to use Mosaic.  The copy I
have is dated May 8, 1993.

3) A document written by the folks at CERN, with 'World-Wide Web
server software, Generated from the Hypertext' on the front sheet,
and dated June 2, 1993.  This is a tome of some 7 chapters, including
an HTML style guide and info on a shell script HTTPD server.
This is the one I really want, as it gives a nice overview of the
software available, at least at the time of the writing.  Hopefully
its been updated?

4) Another CERN document.  My copy begins with "Chapter 1 WWW Daemon
user guide" and looks to be a document written with LaTeX.  Chapter 2
is "Hypertext daemon", and chapters 3 and 4 are "The W.A.I S. - WWW
gateway" and "Gateway to VMS Help".

5) Yet another CERN document titled "World-Wide Web: An Information
Infrastructure for High-Energy Physics".  In the footnote it states
the document is a preprint of a paper presented at "Software
Engineering, Articicial (sic) Inteligence and Expert Systems for High
Energy and Nuclear Physics" in January, 1992.

If you know where I can get my hands on any of these documents, or any
other documents which effectively describe the WWW or WWW specific
programs (such as Mosaic, various httpd implementations and the like),
I would appreciate being given the document, or at least an ftp
address (I can find a host to ftp from in an emergency).  URLs won't
do me much good.

Thanks for your help.

---------------------------------------------------------------------
Instrument Approach Procedures Automation             DOT/FAA/AMI-230
---------------------------------------------------------------------
Bryan D. Oakley                   ctrbdo%iapa@...
KENROB and Associates, Inc.              voice: (405) 954-7176 (work)
5909 NW Expwy Suite 209                         (405) 366-6248 (home)
Oklahoma City, Ok.  73132

Found this on the comp.multimedia newsgroup.  Everyone provide your input -
maybe it will
be what everyone has been wanting. (or at least the beginnings of something that
can be
polished up by someone else if they don't quite make it)

----------------------------------------------------------------

In article <2gueru$m94@...>, reich@... (stephen
reichenbach) writes:
I am assigning the students in my Multimedia Computing Seminar to
write a WYSIWYG HTML editor for the X Window System (to be done as
a group project).  We plan to make the program available.

I am writing this note to request from interested users suggestions
about the design, functionality, etc. of this project.

Please post your suggestions so that others in the community will
have an opportunity to expand or comment on others' suggestions.

Thank you.

Steve Reichenbach (reich@...)

--
Pat McClanahan  Internet:mcclanah@...
EROS Data Center 		 mcclanah@...
Sioux Falls, SD
605-361-4607

>There is constant confusion about what the CGI specifies.  Let's
>make it clear:
>
> CGI specifies the interface between HTTP server and
> a script: the command line args, environment variables,
> standard input and standard output.
>
>CGI has NOTHING WHATSOEVER to do with how a server decides if
>a file is executable or not.
>
>One server writer could use x-bits to resolve executability.
>Another could use a fixed cgi-bin directory and a fixed prefix in
>URL pathname.  Another can have many of them, with generic mapping
>scheme.  Yet another can just list them in its config file.
>It's all up to server implementation.

This compartmentalization of protocol specs has its advantages,
but if you step back for a second, what you've just said is that
we're deliberately designing things so as to minimize portability
of HTTP/CGI/HTML works among servers.  Someone porting a corpus
that includes scripts is going to have to harvest all the
out-of-band signals and re-specify the information in the foreign
server's config files, exec bits, suffix, or whatever.

Yes, I realize we're not going to have portability of scripts
across platforms, but we seem to be explicitly defining away
compatibility across servers, even running on the same OS.

/Rich Wiggins, CWIS Coordinator, Michigan State U

Larry Masinter writes:

> In reviewing the HTML design, try to keep in mind folks with an audio
> interface, who expect the document to be read to them. There are lots
> of ways to render a heading or a title in spoken language, and even a
> way to render 'emphasis', and even varying degrees of emphasis.
> However, it's very hard to render 'bold'.

In using emphasis authors would like to be sure that a given set of
emphasis tags will in fact be rendered differently on *ALL* browsers.
The precise way these are differentiated will clearly depend on the
characteristics of each browser, on dumb terminals email conventions
could be used while on others color and font attributes can be used.

Now, while we could use neutral names such as <HP0> <HP1> ... <HP4>
most of us would prefer more meaningful names which convey the common
interpretation. This explains why <B>, <I> etc are well liked.

The problem with "logical" emphasis tags is there is no easy way of
pulling together an effective small set. In my attempts to do so for
HTML+, it rapidly became apparent that this is a bottomless pit.
The set in the DTD provides just a few extras to those in HTML, perhaps
leaning too far towards the needs of computer manuals. As for <EM> and
<STRONG> these are ok for some purposes, but comprise too small a set.

Dave Raggett

Dave was looking for a more permanent place to put "Minutes of
WWW/TEI meeting for last Noveber".

You can now find it on the University of Limerick server:

<A HREF="http://itdsrv1.ul.ie/Research/WWW/cork_tei_www.html">Minutes are
here</A>


Liam

--
      Liam Relihan        | Voice: +353-61-333644 ext. 5015   |     _ | __ \
  CSIS, Schumann Building | Fax:   +353-61-330876             |    |  | |   |
  University Of Limerick  | E-mail: relihanl@...            |    |  | __ /
         Ireland                                             ____|____|_|  _\

Ari Luotonen writes:
> Mark A. Krause wrote:
...
> > What if I want to run a server on a DOS PC or a Macintosh?  I think it is
> > important to make sure that GCI is not OS specific.  The continued growth
> > of the Web is going to depend upon how easy it is to get new servers up
> > and running.  Not everyone is going to have access to a UNIX system for
> > this.
>
> There is constant confusion about what the CGI specifies.  Let's
> make it clear:
>
>  CGI specifies the interface between HTTP server and
>  a script: the command line args, environment variables,
>  standard input and standard output.
Just to be clear, the CGI *is* OS specific because it requires things like
command line arguments, environment variables, and stdin/stdout.  I don't
think you can define an interface at this level without being somewhat
OS specific.

> CGI has NOTHING WHATSOEVER to do with how a server decides if
> a file is executable or not.

You are correct that CGI *does not* specify how to determine if a file is
executable but let me clarify that CGI does (potentially) impact the URL.
If scripts are to be portable then the URLs themselves must be portable.
That means that CGI must also define how the server decodes the URL (to
some extent anyway).

Let's consider all the known schemes for determining "scriptability":
	 ;
	 cgi-bin
	 .cgi (or other magic extension)
	 xbit
	 config file
The portability constraint requires that any scheme adopted must work on
all servers.  So, if a scheme requires special processing by the server
(like ";" might, depending on how it's used) then it must be covered by
the CGI spec.  e.g., http://server/foo;/arg1/arg2 is probably ok but
http://server/foo;arg1/arg2 is not.

There isn't anything wrong with adding special decoding in the server for
some format (e.g., forms), but it will require coverage in the CGI spec
and all CGI servers must support it (or else it's not really useful).

--sanders

Rob McCool feeling sorry for me:
> I feel sorry for Ari, wherever he is, getting back to all 3000 lines of this
> argument.

I'm back, I've just been quiet watching you handle it very well :-)

As for the whole discussion about semicolons et al, I'm against it
simply because it makes scripts non-seemless.  I may have a huge
amount of some information in some format, lets take a simple example
of httpd log files.  I have what seem to be files:

	 /httpd/statistics/1993/Dec/ByHost.html
	 /httpd/statistics/1993/Dec/ByDomain.html
	 /httpd/statistics/1993/Dec/ByDocument.html

I may first implement this as a script that takes the year (1993),
month (Dec) and target format (ByWhatEver.html) as its arguments,
and generates it from a single file stored somewhere is some format.

Two months later I'll notice, oh shit, this wastes *so*much* CPU
time -- I'll just create these files after the end of each month.

Two years later I naturally run out of disk space, and also know
that only the few latest months are usually referenced.  So I'll
remove all the By*.html files execpt this year's ones, and
reintroduce my statistics script to generate older ones from a
single compressed log file.

This would be a mess with semicolons going back and forth.

I don't care if someone starts using these ;'s in his or her
URLs, especially as it is CGI/1.0 compliant as Rob mentioned,
for my server the rule file can certainly be used to strip
them away anyway, if necessary.  But always requiring ; to
terminate the script name is bad.

The example above is what I regard as the most important aspect
of scripts, and it would kill me to see it destroyed.

-- Cheers, Ari --

help

>
> Larry Masinter writes:
>
> > In reviewing the HTML design, try to keep in mind folks with an audio
> > interface, who expect the document to be read to them. There are lots
> > of ways to render a heading or a title in spoken language, and even a
> > way to render 'emphasis', and even varying degrees of emphasis.
> > However, it's very hard to render 'bold'.
>
> In using emphasis authors would like to be sure that a given set of
> emphasis tags will in fact be rendered differently on *ALL* browsers.
> The precise way these are differentiated will clearly depend on the
> characteristics of each browser, on dumb terminals email conventions
> could be used while on others color and font attributes can be used.
>
> Now, while we could use neutral names such as <HP0> <HP1> ... <HP4>
> most of us would prefer more meaningful names which convey the common
> interpretation. This explains why <B>, <I> etc are well liked.
>
> The problem with "logical" emphasis tags is there is no easy way of
> pulling together an effective small set. In my attempts to do so for
> HTML+, it rapidly became apparent that this is a bottomless pit.
> The set in the DTD provides just a few extras to those in HTML, perhaps
> leaning too far towards the needs of computer manuals. As for <EM> and
> <STRONG> these are ok for some purposes, but comprise too small a set.
>
> Dave Raggett
>
What about my suggestion at the WWW/TEI meeting to have 4-6 different
kinds of emphasis.  For instance <em1>,<em2>... or <em a>, <em b>....
The different kinds wouldn't neccessarily be any kind of precedence
order but would simply specify DIFFERENT kinds of emphasis for each
of the tags.  That way you could specify different words to be
emphasised and be sure that each emphasis style will be unique.

The problem is that there is only a limited number of ways to
show emphasis, especially on non graphical terminals, so if you
define 20+ kinds of logical emphasis they all get mapped to a
smaller set of physical styles.  In many cases you could specify
two different logical emphasis and they will get rendered
EXACTLY the same.  As a document writer it would be nice to be
able to know that text marked with different emphasis tags
will indeed be shown in a different styles.  Specifying a
smaller set of somewhat logical emphasis tags that will have
unique physical renderings will solve this problem.

:lou
--
   **************************************************************************
   *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
   *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
   *                         Kuhub.cc.ukans.edu      ACS Computing Services *
   *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
   *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
   **************************************************************************

> I am assigning the students in my Multimedia Computing Seminar to
> write a WYSIWYG HTML editor for the X Window System (to be done as
> a group project).  We plan to make the program available.
>
> Steve Reichenbach (reich@...)
>
WYSIWYG or WYSINNWOS (What You See Is Not Necessarily What Others See)??
If viewers are configurable, wrt font sizes and faces...  This
is the whole problem with the <whitespace> discussion (mixing metaphors).
X-HTML GUI editor?  Bring it on!

bob jernigan

Hi...

Someone posted a survey of www clients a while back in a nice chart format
that listed their capabilities.  Could someone point me to the latest rev
of such a beast?  Thanks.

Also, how's the NCSA Mac/PC groups doing on the next rev?

-bob kaehms

Mark A. Krause wrote:
> On Dec 30,  9:09pm, Charles Henrich wrote:
> >
> > I still say we go with the execute bit, 1000 times more flexible and simple
> > than any other method on the planet.
>
> What if I want to run a server on a DOS PC or a Macintosh?  I think it is
> important to make sure that GCI is not OS specific.  The continued growth
> of the Web is going to depend upon how easy it is to get new servers up
> and running.  Not everyone is going to have access to a UNIX system for
> this.

There is constant confusion about what the CGI specifies.  Let's
make it clear:

	 CGI specifies the interface between HTTP server and
	 a script: the command line args, environment variables,
	 standard input and standard output.

CGI has NOTHING WHATSOEVER to do with how a server decides if
a file is executable or not.

One server writer could use x-bits to resolve executability.
Another could use a fixed cgi-bin directory and a fixed prefix in
URL pathname.  Another can have many of them, with generic mapping
scheme.  Yet another can just list them in its config file.
It's all up to server implementation.

	 CGI guarantees that *scripts* written for one CGI server
	 indeed work on another CGI compliant server.

A script can be detected executable in numerous ways -- never mind
how it's done.  In any case, once the server has somehow found out that
a file is an executable CGI script, it WILL call it in a manner described
in CGI/1.0 spec.

-- Cheers, Ari --

In regards to my earlier request for postscript documentation on the
Web:

Many thanks to all who responded.  I've now got the docs I was looking
for.  I appreciate the speedy replies.

---------------------------------------------------------------------
Instrument Approach Procedures Automation             DOT/FAA/AMI-230
---------------------------------------------------------------------
Bryan D. Oakley              ctrbdo%iapa@...
KENROB and Associates, Inc.              voice: (405) 954-7176 (work)
5909 NW Expwy Suite 209                         (405) 366-6248 (home)
Oklahoma City, Ok.  73132