From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199407082003.AA14644@oit.gatech.edu>
Subject: Re: New URC Specification is ready....
To: davis@DRI.cornell.edu (Jim Davis)
Date: Fri, 8 Jul 1994 16:03:36 -0400 (EDT)
In-Reply-To: <199407081333.AA26477@willow.tc.cornell.edu> from "Jim Davis" at Jul 8, 94 09:33:27 am
Jim Davis said this:
> 1) Perhaps the URC itself requires some meta-data, e.g. the date/time
> it was created and the server from which it came. See comment about
> TTL below. I am assuming that one might want to keep a URC for
> minutes, days, even forever, like a card in a card catalog. In that
> case the meta-info becomes more important.
True.
> 2) I think the precedence rules are a mistake because they are not
> flexible. For example, right now, a TTL is associated with the
> previous tuple only. But suppose you wanted to add another entry that
> was just like the TTL, in that it refered to one and only one entry.
> You could not do it, since which ever one came second would not get
> the right target. e.g. you want to say
> URL: foo
> Cost: $25
> TTL: 1 day
> Bandwidth: low
>
> In your system the TTL would apply to Cost not to the URL. (Hopefully
> the indenting makes my intent clear. Indeed I would claim that you
> should use indenting, except that you use leading whitespace as a
> continuation character.
What about a rule like this:
URL:foo
TTL: 36000
Cost: $25
Bandwidth: low
This means that:
a) the URL has the TTL of 3600.
b) the URL has precedence until the next occurence of URL:
c) therefore, since everything until the next URL DEPENDS on that URL,
when it expires then everything in that tuple expires.
Does that make sense?
> 3) How could you record negative information, e.g. suppose you want
> to write down the fact that a certain URL *used* to work, but no
> longer does?
Hmm...Maybe a negative TTL? ;-)
TTL: -3600
i.e.: this worked yesterday but not today.
hehe....this one could get funny...
> 4) You need to specify what character set you wish to use and how
> extensions to the char set will be encoded, e.g. names in non-ASCII.
Good point. I missed that one. I'll add it next iteration.
> 5) what if the attribute contains a colon? Is there a way to encode
> it?
No attribute can contain a colon. If there is sufficient uproar raised then
we can come up with some escaping mechanism but I hate to clutter the
specification with it.
> 6) is whitespace after the colon significant or not?
Yes. This ommision was pointed out after I sent it out. If there is
white space after the : then leading white space in the value is
non-significant. If there isn't one then leading white space IS significant.
> 7) Author. How will multiple authors be encoded? How about Corporate
> Authors? It would be useful to get a clear standard on this so that
> URCs can function as bibliographic records.
I'm not aware of any work that has been done in other areas. That doesn't
mean that there isn't any. ;-) Corporate Authors: sounds reasonable as well.
Multiple Authors could be delimited with a semicolon
> 8) What is the time origin of TTL? Seconds since when?
Seconds since whoever said so. Icky ain't it. I expect TTL to evolve a
great deal before it gets really useful. Maybe a full TTL field with
different encoding methods and such.
> 9) Is anyone thinking about how to express terms and conditions of
> intellectual property usage? I don't think these should necessarily
> go into the URC (a pointer to the info would be better.) nor should
> the URC spec be delayed while these are designed. But they are
> very important issues and *someone* should think about them.
Definilty. This is the how things should progress. We develop other useful
things without slowing down the overall architecture. I don't know all of
the issues relavent in this area but I'm sure someone on this list should.
;-)
> 10) Finally, two trivial issues:
> 1) the HTML document would be easier to read if you used DL instead
> of IL. It would also make it easier to automatically find the
> attributes, since they'd be tagged with DT.
So noted. To be changed next week in the HTML version.
(I love living documents!)
> 2) In the example of Abstract, you spelled "laden" wrong.
hmm...ispell missed that one......
> best wishes
Thanks for the comments!
-MM
-- ------------------------------------------------------------------------------ <HR><A HREF="http://www.gatech.edu/michael.html"> <ADDRESS>Michael Mealling</ADDRESS> <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>