Re: IAFA templates: a user's comment

Martijn Koster <m.koster@nexor.co.uk> Fri, 24 March 1995 09:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00605; 24 Mar 95 4:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00601; 24 Mar 95 4:46 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa01507; 24 Mar 95 4:46 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA15748 for iafa-out; Fri, 24 Mar 1995 04:46:38 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA15743 for <iafa@services.bunyip.com>; Fri, 24 Mar 1995 04:46:34 -0500
Received: from lancaster.nexor.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09995 (mail destined for iafa@services.bunyip.com) on Fri, 24 Mar 95 04:46:05 -0500
Message-Id: <9503240946.AA09995@mocha.bunyip.com>
Received: from nexor.co.uk (actually host victor.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (PP); Fri, 24 Mar 1995 09:45:39 +0000
To: Thomas Krichel <ecs1tk@surrey.ac.uk>
Cc: Martijn Koster <m.koster@nexor.co.uk>, iafa@bunyip.com
Subject: Re: IAFA templates: a user's comment
In-Reply-To: Your message of "Fri, 24 Mar 1995 08:20:56 GMT." <9503240820.AA27851@central.surrey.ac.uk>
Date: Fri, 24 Mar 1995 09:45:36 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martijn Koster <m.koster@nexor.co.uk>
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk

Thomas Krichel wrote:

>   Martijn Koster writes:
>
> ...
> 
> > The variant part of the IAFA templates are a quick fix for a small
> > domain of problems surrounding manifestations of a
> > document. Personally I'd like to see it removed altogether, but it'll
> > have to stay in for backward compatibility.
> 
>   Can you give us an idea what the replacement will look like and maybe
>   a date at which we may expect another version.

Who mentioned a replacement? :-) Seriously though, I don't have a good
solution that is completely general, and yet simple (ie with a chance
people might get it right). So I don't have a date either :-)

I have the feeling that the syntax used by the IAFA templates (or more
generally any simple attribute/value record scheme, as used by X.500,
whois++, harvest etc) are just not suited for describing the level and
more importantly the interdependencies of data elements _within_ a
record that you require. Of course others might disagree. Something
like Stanford's PRDM might be more flexible for that sort of thing.

> > I don't think it's appropriate for the IAFA templates to attempt to
> > solve all the issues, especially when it impacts the templates main
> > selling point, simplicity.
> 
>   I would warn against making the templates to simple. The emphasis
>   should be on giving a good description, and have some people watch
>   that the info provided  does not contain too many mistakes. That
>   would be the point of an intermediary like WoPEc.

Sure, ALIWEB also filters out bogus templates. But someone somewhere
is writing the template, probably by hand, and probably without having
read all $$ pages of the iafa draft. So it _has_ to be simple.

> > I tend to think of a resource as a "something on the internet", that I
> > can point to. The variants came in to fix the case where two resources
> > are the same intellectual content. Describing parts however, splits
> > the resource up, I can no longer point to it, the parts don't have the
> > same intellectual content. So the parts are resources themselves.  If
> > they're not meant to be, because they're part of say one document,
> > then this document should be made available as a resource
> > (tar/zip/stuffit whatever).
> 
>   Yes, I agree with that, but in practice it is a problem because
>   there are a number of different archivers arround and because some
>   publlishers do not compress/archive their resource. They do not care
>   to do that. Emailing them is useless, they do not reply. 
> 
>   Let me add: If the templates are made to describe a single file, then
>   this should be said so in the doc. IMHO this would be quite a severe
>   drawback.

I suppose it could refer to multiple files by pointing to a directory?

> > We need to draw a line somewhere; otherwise we'll be talking about
> > URL-v0-p1-e2-l3 to describe a gzipped copy on a european machine of
> > part 1 of an english variant of a document, etc. We cannot solve all
> > problems in one. I'm very, very wary of making it more complex than it
> > is at the moment.
> 
>   I very much agree with this. Have a good day!

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
WWW: http://web.nexor.co.uk/mak/mak.html