Revised WD, charter etc.

All:

>> > drafthttp://www.w3.org/member/WWW/TR/WD-logfile.html
>> Yes. Tried to look at your draft, but it was password-protected.

>This seems to be a recent change. I've looked at it in the past -
>often enough to have a server logging it and have fixed my simple
>analysis tool to use it.

Ooops, try :
http://www.w3.org/pub/WWW/TR/WD-logfile.html

Its the same resource but I accidentaly gave out the member URI.

Also see :
http://www.w3.org/pub/WWW/Demographics/Logging-Issues.html

Which is a quick 'n dirty charter and issues list. If people want to add issues
to the list please mail to the mailing list and tag the issue you want to raise 
with the word ISSUE: in upper case. This will help me to fish out issues people 
want to have recorded. I'm assigning a code number to each issue raised in the 
hope that I'll be able to use some automated management tool at some point.


I have revised the draft, mainly to clean up the various typos etc in the 
original draft. It should now be OK except for not specifying where the BNF 
comes from - its the same as used in the HTTP draft but I'm not sure whether to 
import the HTTP grammar or repeat it.


>> So why should this be in the log rather than in some higher-level
>> demographic mechanism? In order to ensure its universality. Where does
>> the geographic information come from? Perhaps a one-time browser setting.
>> Perhaps a more dynamic mechanism. The trick would be to ensure consistent
>> identification of the location.

>Doing that is outside the scope of this list. As a one-time browser
>setting, it belongs to http.

I think that it would be relevant to consider offline methods of augmenting the 
log file. such as downloading autonamous service lookup tables from a router to 
permit a rough estimate of geographic locaton.

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. If a an analyser does not understand a field is there a need for it to 
know its type?

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
	
[c, r, s are in use already:]

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.


		Phill

Received on Saturday, 23 March 1996 16:02:21 UTC