Re: about use of AFA format

[Markus Stumpf <[e-mail]>]

[e-mail] (Rafal Maszkowski) writes:

>      3.6.3 MISCELLANEOUS
>      The following is a list of generic data element subcomponents used
>      when referring to particular resources. These can be added to any
>      of the templates described below.

>Can they be added many times? I guess not..

I don't know if I understand you right.
There are two naming schemes (3.4.1, 3.4.2).
3.8.3 (SERVICE information) contains:
[...] Filename for this index file (Naming scheme 1): AFA-SERVICE
[...] any number of these files may exist in the archive.

So it is pretty valid to have a file like ("minimal form" ;)) ):
------------------------------
Template-Type:	SERVICE
Title:		WAIS database of the IAFA templates in our FTP archive
URI-v0:		gopher://gopher.informatik.tu-muenchen.de/77/.wais-db/ftp-index
URI-v1:		wais://wais.informatik.tu-muenchen.de/ftp-index
Description:	all the IAFA templates for software and documentation are
	fed into a fulltext database that is updated every night

Template-Type:	SERVICE
Title:		WAIS database on the files in the WWW area
URI:		wais://wais.informatik.tu-muenchen.de/www
Description:	all HTML files on our WWW server are fed in a fulltext
	database that is updated every night.
------------------------------

>It would be convenient to have multiple Description-v* and URI-v* (and
>others) in SERVICE template.

I agree that URI should be a variant field, too, as one resource may
be accessible through various mechanisms (the most common I think is
currently that the same information is accessible through gopher, http
and ftp).
But I don't see the need for a variant description field.

>The same with mailing lists - the running list itself and its archive
>isn't exatly the same but I would prefer to have information about
>subscribing and ftp achives URIs, listserv archive URI and comment,
>gopher archives URIs and News group URI in one template. Mailing list
>and Usenet group where is it gatewayed to are obviously equivalent.

Why don't you put the additional information in the Description: field?
And please note that there is a Template-Type: MAILARCHIVE and USENET
which allows exactly for the the archiving of mailing-lists and
newsgroup archives.
You could e.g. have a file (scheme 2) fishlovers.AFA:
------------------------------
Template-Type: SERVICE
Title: 	       fishlovers
URI:           mailto:[e-mail]
Admin-Name:    Ima Adams
Admin-Email:   mailto:[e-mail]
Registration:  Send mail to the administrative address with your
 	       own email address requesting addition
Description:   Discussion list for people who love fish of all types
    	       This list is archived at ftp://foo.com/archives/fishlovers
	       and also accessible via gopher at
	       gopher://foo.com/11/archives/fishlovers. This mailing-list
	       is also gatewayed to the USENET group rec.fish.lovers
Keywords:      fish, aquarium, marine, freshwater, saltwater
Access-Policy: Any Internet user may subscribe to this mailing list

Template-Type:	MAILARCHIVE
Title:		fishlovers
URI-v0:		gopher://foo.com/11/archives/fishlovers
URI-v1:		ftp://foo.com/archives/fishlovers/
Keywords:       fish, aquarium, marine, freshwater, saltwater
Description:	This is an automatically maintained archive of all mails
		sent to the fishlovers mailing list.
------------------------------

However, here too, one could make URI a variant in the SERVICE template
and allow for adding e.g. a
URI-v1:		news:rec.fish.lovers


>Another use of multiple URI-v*s etc. would be in LARCHIVE.

I don't think so. With the LARCHIVE file the placement in the file
structure is significant! Thus I think the URI is unique anyways.

>The order of the fields is not specified (if I'm not wrong). It is
>good because I'd like to have always Title field as the first one

Hmmmm ... I thought we had the convention that Template-Type: has
to be the first field and for all others the order is free, but I
can't find it anymore in the draft.

But I found something other:
    3.4 FILE NAMING (3rd paragraph)
and
    3.4.2 (2)
Is there any reason to prohibit multiple records with naming scheme 2??
As in the above example with the SERVICE and MAILARCHIVE I think it may
be very useful to allow for more than one record even with scheme 2.
Having > 5 such lists and archives would make it easier to maintain that way,
than with scheme 1 and one big file.
Also in 3.4 (3rd paragraph) is "[...] one large file containing all templates".
I can't see that fit even with scheme 1, as there is no type independent
name for such a file with scheme 1.

	\Maex
-- 
______________________________________________________________________________
 Markus Stumpf                        [e-mail] 
                                http://www.informatik.tu-muenchen.de/~stumpf/