Re: Utrecht archive announcement and proposal

---------

Nancy McGough (nancym@ii.com)
Mon, 27 Nov 1995 09:59:46 -0800 (PST)


On Mon, 27 Nov 1995, Martin Leese - OMG wrote:
> This is not good:
>
> >> From: Nancy McGough <nancym@ii.com>
> ..
> >> Latest: http://some.site/some/file.html
> >> Author's home page: http://some.site/some/file.html
>
> For the reasons stated by:
>
> >> "Lennart Regebro" <lennart@bump.traffic.is>
> ..
> >> The key to a successful standard is to make one that is simple *and*
> >> flexible. Yours [Nancy's] is simple, but non-flexible. Hank Pennings is
> >> flexible, and (in my opinion) simple. I do think it's *ugly* but I
> >> can't really find any better solutions.

Why do you guys think that my proposal is not as flexible as Henk's?
It seems to me that they are the same in terms of flexibility, i.e.:

URL: url "meaningful text"

and

meaningful text: url

have the same content and flexibility. I can easily convert from one
to the other.

But, if you allow different text to be used instead of the leading
"URL:" then I agree that Henk's proposal is more flexible and I do
like this flexibility. What do you all think of the following for
auxiliary headers:

Meaningful_Auxiliary_Header: <URL:url> "meaningful link name"

For example, the Pine FAQ could have these auxiliary headers:

Official_FAQ_Location: <URL:http://www.washington.edu/pine/faq/> "University
of Washington"
Related_Info: <URL:http://www.yahoo.com/Computers_and_Internet/Software/Electronic_Mail/Pine/>
"Yahoo's Computers and Internet:Software:Electronic Mail:Pine"

Things to note about this proposal:
* The <URL:url> notation will make it so that URLs are clearly
flagged and long URLs will not be broken. We would use whatever
is the standard container for URLs (is <URL:url> the latest
container standard?).
* Any text would be acceptable for the Meaningful_Auxiliary_Header
and the "meaningful link name."
* The Meaningful_Auxiliary_Header will be a string of characters
without white space - spaces between words are replaced with
underscores. This will make auxiliary headers similar to
regular headers.
* Auxiliary headers can use multiple lines by starting the
continued lines with white space (again this is the same as
standard headers).
* We would come up with a list of standard URL auxiliary headers for
pointers to URLs. These standards would be useful in terms of
usability (e.g., users would always know that Official_FAQ_Location
is where the latest and greates version of the FAQ is) and also
in terms of FAQ automation tools (e.g., my FAQ launchers).
* FAQ maintainers could choose to use whatever URL auxiliary headers
that they needed: standard or custom or a combination of these.

Please take a look at my FAQ launchers to see what I'm trying to do
and I welcome any suggestions for headers that will help to automate
the creation of the FAQ launchers.

Thanks much,
Nancy

PS - The FAQ Launchers, which I'm constantly updating, are accessible
through:

http://www.best.com/~ii/faqs/

<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<
@..@ Nancy McGough /\_/\
(----) Infinite Ink ( o.o )
( >__< ) http://www.jazzie.com/ii/ > ~ <



[ Usenet Hypertext FAQ Archive | Search Mail Archive | Authors | Usenet ]
[ 1993 | 1994 | 1995 | 1996 | 1997 ]

---------

faq-admin@landfield.com

© Copyright The Landfield Group, 1997
All rights reserved