Message-Id: <6.1.2.0.2.20050403212027.04aed090@mail.jefsey.com>
Date: Sun, 03 Apr 2005 21:22:17 +0200
To: ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Registry in record-jar format
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

On 13:26 03/04/2005, Debbie Garside said:
>Hi Miska
>
>You wrote:
>
> > This is the second time you've used the word "concise"
> > in a way that is unfamiliar to me.  Please clarify what
> > you mean by it.
>
>My meaning is in the strict English sense, as taken from the OED, "giving a
>lot of information clearly but in few words".
>
>In this instance I feel that date as opposed to year is more
>precise/concise... (precision is also top of my agenda) however, as
>previously stated, everything is up for discussion and if there is a clear,
>valid reason for having just "year" I am very interested.

Misha,
date includes year. precision is relative. There are cases where date is 
needed (for example to sort standards, or "first come first serve" 
cases).  There are cases where year is enough. And is more consise as well 
as more precise due to the errors the date treatment can introduce.

For example the date depends on a format, the year not. The date is often 
on 4 bytes, the year can be on 2 or less. If the date is presented with an 
appropriate ascii format, the year is part of it and you have 2 information 
for the digital cost of one, etc. If you list the year first, month and day 
in digits you also get yourself a precise sorting order. If you concatenate 
the and may be a part of a unique string, you have a unique ID you can then 
scramble with an MD5 to obtain a unique stable 32 bytes anonymous ID 
suitable for a random sorting or protection. This is a way to get 3, 4, 5 
or more information one shot. "consise" seems therefore the most 
appropriate word.

As many noted in term of size of a base (which is very different from 
resulting traffic generated by an application) we are not concerned by the 
size but by the apparent complexity of access translating in delays, 
added/biased noise, time, simplisity, surety, security and flexibility of 
update and access, risks of error, database consistency, versatility and 
independence from formats, % availability, involved costs, etc.. So 
conciseness is a complete thinking, including data collection, management 
and dissemination processes, openess, delays and costs. This is precisly 
the issue here.

Debbie is here working one of the most important issue. This is why I do 
not think we can reach anything final before having read what the ISO 639 
group comes with on the matter.

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru