Typeing of fields

> On the issue of finding out the types of entries I had assumed that this was
> unnecessary. The grammar should permit a parser to determine the boundaries
> between fields by searching for whitespace and taking into account quoted
> fields.

That would work. It would be easier in some languages (those that
provide a "get the next word" facility) if this can be determined from
the #Fields: directive. Since I have that, I used it:

	if line.field.quoted: value = getword(line)
	else
		/* Parse the thing by hand */

Since making the format "Perl friendly" is an issue, I think it's
reasonable to make it friendly for other languages as well.

> If a an analyser does not understand a field is there a need for it to
> know its type?

If it's going to do something with the field, the analyzer has to know
the type. It can either be told by the user, or figure it out from the
name. Since it's got a list of field names, figuring it out from the
name lets me write an analyzer that a user can instruct to "find the
mean and mode of all numeric fields" and similar things. I think this
is a good idea.

> As specified all fields derrived from content lines are strings. Is there a
> value in enforcing some type system on x- extension fields. Eg we could have
> i-      Integer
> f-      fixed
> u-      uri
> d-      date
> t-      time
> n-      name
> a-      address
> x-      string  (cannot be s because of conflict with server.)
> Is this too complex for people or should we make it as easy as possible for
> analysers? I think the latter is a good plan.

Fine by me.

Two additional things:

In looking over the new HTML draft, you still need to move "bytes
transferred" from the "does not require prefix" to the "prefix
required" areas.

I don't particularly care about the ':' in directives; I was just
curious as to how something that apparently obscure got into it.

 	<mike

Received on Saturday, 23 March 1996 18:14:09 UTC