Re: Comments on draft-ietf-iiir-publishing-01.txt
Markus Stumpf <stumpf@informatik.tu-muenchen.de> Sat, 09 July 1994 18:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02162; 9 Jul 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02158; 9 Jul 94 14:49 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa08204; 9 Jul 94 14:49 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01690 on Sat, 9 Jul 94 14:05:21 -0400
Received: from sifon.CC.McGill.CA by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01681 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Sat, 9 Jul 94 14:04:47 -0400
Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id OAA28977 for <iafa@cc.mcgill.ca>; Sat, 9 Jul 1994 14:04:37 -0400
Received: from hpsystem1.informatik.tu-muenchen.de ([131.159.0.176]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <326489>; Sat, 9 Jul 1994 20:04:24 +0200
Received: by hpsystem1.informatik.tu-muenchen.de id <231522>; Sat, 9 Jul 1994 20:04:09 +0100
To: iafa@cc.mcgill.ca
Path: stumpf
X-Orig-Sender: USENET Newssystem <news@hpsystem1.informatik.tu-muenchen.de>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
Newsgroups: lists.iafa
Subject: Re: Comments on draft-ietf-iiir-publishing-01.txt
Date: Sat, 09 Jul 1994 21:03:58 +0200
Organization: Technische Universitaet Muenchen, Germany
Lines: 254
Message-Id: <2vmoqe$8t9@hpsystem1.informatik.tu-muenchen.de>
References: <2uv0dg$5c0@hpsystem1.informatik.tu-muenchen.de>
Nntp-Posting-Host: hphalle0.informatik.tu-muenchen.de
Cc: m.koster@nexor.co.uk, bajan@bunyip.com, maex@leo.org
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
X-Newsreader: NN version 6.5.0 #5 (NOV)
Sorry it took me so long to comment, but I am rather busy learning for my finals, so ... :/ Martijn Koster <m.koster@nexor.co.uk> writes: >I look forward to your comments, Here we go :) I'd like to add a few comments to your posting as well as a few things I'd like to see. (If not stated otherwise I totally agree with Martijn's statements) ------------------------------------------------------------------------ >3.6.1 >It seems to me that Organization-Name and Organization-Type do not fit >into the template very well, where are the other ORGANIZATION* >elements, especially Handle? I suggest explicitly mentioning >ORGANIZATION* elements can be part of USER*, or adding an element >User-(ORGANIZATION*). I second that. If there shall be some organizational attachment to a USER cluster we should have the full ORGANIZATION* elements. Thus I'd also suggest to exchange 3.6.1 and 3.6.2 However, why is 3.6.1 named "INDIVIDUALS AND *GROUPS*" ?? I can't the GROUPS fit very well into the USER cluster. And if we don't assume a organization to be commercial (as I do usually ;) ) I think they'll better fit with the ORGANIZATION cluster and the sections should be 3.6.1 ORGANIZATIONS AND GROUPS 3.6.2 INDIVIDUALS --- on 3.6.3 MISCELLANEOUS: I think this section may be completely deleted. There is no relevant information that is not repeated later on in the exact template definitions and may lead INHO to confusion. --- >What is the relationship between Title, Short-Title, and things like >Name in normal templates? Are Title and Short-Title recommended for >all templates, if not what point is really served by them being there? I always had problems with this, too. I think Shot-Title is unnecessary, als we have Title and Description and so Title could be used for short infos and Description for longer ones. BUT: Title mainly applies to the DOCUMENT type. All other types would better do with a Name tag. This tag is also used with all but the OBJECT types. I don't kniw whether it would be valid in good english to speak of the name of a document instead of the title (in Germany it would ;)) ) but if, I'd like to see the use of Name instead of Title in all templates. This would make it also simpler to parse. --- 3.7.3 >The definition for *-Location-v* mentions a URL for the first time, >without definition or reference. I suggest these become "URI", or >preferrable, the entire document uses URL's. This is my fault as I have created the template and the example. :) --- 3.8.1, 2.1 and other places >I feel a bit unhappy about the use of handles without giving any indication >of how they are to be used other than : >> NOTE: A handle should be used in preference to a fully expanded entry >> in those situations where a handle for an individual, group or >> organization can be obtained and subsequently resolved by some other >> (external) method (directory service). >There should be an indication of uniqueness, are Handles supposed to be >unique withing a multi-record document, a site, or world-wide. Would there any problem allowing URIs (or URLs) as handles? Thus I could simply use Author-Handle: http://www.leo.org/~stumpf/ and on this page you'll probably find (or at least should find) all the information that usually is in the USER* cluster. Most of the organizations, groups or individuals I've checked have such "HOME pages", so it will be a good start. Allowing URIs for Handles is IMHO also a good start as it is flexible and may be changed to a URI poiting to some kind of directory service some time in the future. --- 3.8.3 >Why serviceS when everything else is singular? Hehe ... asked this twice but never got any reaction ... I'd like to have the "s" deleted, too!! --- 3.8.4 >Author-(USER*), Admin-(USER*) "may be repeated as often as necesarry" > >Hmmm... Why are these for multiple people here, and not anywhere else? >How can we parse this, when you don't know where one person begins >and another ends, e.g. > > Author-Name: Martijn Koster > Author-Email: emtage@bunyip.com > >When parsing IAFA templates, what should one do with duplicate fields >normally? I consider them an error. We had this with my question about authors of e.g. songs. Alan Emtage wrote: ae> Now we have a potential problem. Which home phone number belongs to which ae> Author? My only solution is to put an ordering. In cases like this when *you ae> are dealing with the same object* and you have repeated fields that have to ae> be associated, positional association is the only thing that I can see ae> working. So, in the example above, since we have an Author-Home-Phone we ae> associate it with the last Author-Name previous to it. ae> ae> Now, we have to be very careful how we specify this. Take this example: ae> ae> Template-Type: SOUND ae> Title: Southern Cross ae> Author-Home-Phone: +1 800 555 1212 ae> Author: Crosby ae> Author: Stills ae> Author-Home-Phone: +1 415 234 5678 ae> Author: Nash ae> ae> ae> Since we have not made the "Author-Name" special signficance, what does line ae> #3 associate with? You'd probably guess line #4 but since we haven't defined ae> an author can we be sure that it is to associate with "Crosby" ? ae> ae> I suggest the following. For the "clusters" we define that the -Name field ae> must be first within the cluster to disambiguate the above. Think this is a good and workable solution. Same as Template-Type has to be the first in a template file *-Name: should have to be the first in a USER* cluster. Same should apply to ORGANIZATION* as well. --- > ACKNOWLEDGEMENTS I think Martijn deserves his name is added :) > Bibliography: A reference to ALIWEB or a paper on aliweb should be added too, as this is the first widely used service making use of IAFA. (sorry I am at home and wading through my references via a 2400 modem is no fun) ------------------------------------------------------------------------ And here a few comments I haven't seen in Martijn's mail. As told many times before we make heavy use of IAFA for our anonymous ftp archive (ftp://ftp.leo.org/). We now have about 5000 (!) template types (some more, some less filled with information). As soon as the LSM -> AFA converter works this number will raise a lot, again. We currently use this information for providing a HTMLized access to our archive via http://www.leo.org/pub/00-index.html and creating a wais database gopher://www.leo.org/77/.wais-db/ftp-index (we're working on a better access for the database). For all this services and especially for the user it is of big help to have all the relevant information for a object available for cut 'n paste. Currently we only have Access-Protocol, Access-Host-Name, Access-Host-Port and Pathname. (I wonder why Pathname has no Access- prefix?). The example also has a Access-Method which is not listed in the definition. Why can't we define another cluster called OBJECT and have it: Format: Size: Language: Character-Set: ISBN: ISSN: Protocol: Host-Name: Host-Port: Pathname: Library-Catalog: Method: URI: One would then have three choices: 1) URI: for easy access and cut 'n paste 2) Method: a textual description 3) Protocol, Host-Name, Host-Port, Pathname: for better known access methods that don't have assigned a URL type yet. in the AFA-OBJECT then have a Access-(OBJECT*)-v*: or even simpler a (OBJECT*)-v*: Same applies to the SERVICE type, too. --- 3.8.4 Abstract isn't listed in the definition part but used in the examples. I think Description is fine and also used throughout all other templates so Abstract should be deleted. --- 3.8.4 > [ ... ] Suggestions for this types include > > [ ... ] > > Other names may be constructed as necessary. How do I have to read this? Am I free to e.g. create a new type FONT, pick up some data elements that would fit from section 3.8.4 and voila we have a new Template-Type ?? (FONT is e.g. something that I'd missed lately, when some Type-1 fonts were archived and the archivers brought up the question what Template-Type to use) --- *Phew* That's it for now ... Have a nice weekend \Maex -- ______________________________________________________________________________ Markus Stumpf Markus.Stumpf@Informatik.TU-Muenchen.DE http://www.informatik.tu-muenchen.de/~stumpf/
- Comments on draft-ietf-iiir-publishing-01.txt Martijn Koster
- Re: Comments on draft-ietf-iiir-publishing-01.txt Martijn Koster
- Re: Comments on draft-ietf-iiir-publishing-01.txt Markus Stumpf
- Re: Comments on draft-ietf-iiir-publishing-01.txt Martijn Koster
- Re: Comments on draft-ietf-iiir-publishing-01.txt Markus Stumpf