From schwern at pobox.com  Tue Sep  4 23:55:45 2007
From: schwern at pobox.com (Michael G Schwern)
Date: Tue, 04 Sep 2007 15:55:45 -0700
Subject: [tap-l] Update and sign the TAP proposals to reflect reality.
Message-ID: <46DDE271.9060806@pobox.com>

There's a lot of work lately on the TAP::Parser implementing TAP ideas we've
been knocking around for a while.  The documentation of those proposals on the
wiki has been lagging behind.  I've been updating the TAP proposals on the
wiki to reflect how we've been thinking about them lately.  Please join me.

http://testanything.org/wiki/index.php/TAP_Proposals


In particular the TAP Diagnostic Syntax and TAP Meta Information need work to
catch up with what TAP::Parser is actually doing.

http://testanything.org/wiki/index.php/TAP_diagnostic_syntax
http://testanything.org/wiki/index.php/TAP_meta_information


I'm also signing proposals (use the Mediawiki ~~~~ signature) to indicate
for/against.  Some proposals have been promoted in a vacuum and it would be
nice to see what people are thinking.  In particular the rather obvious TAP
escape syntax needs to be un-warnocked and added to the spec.

http://testanything.org/wiki/index.php/TAP_escape_syntax


There has also been discussion of a TAP datetime format on perl-qa which I'd
like to get comment from folks outside of Perl on.

http://testanything.org/wiki/index.php/TAP_datetime


-- 
Stabbing you in the face so you don't have to.


From schwern at pobox.com  Fri Sep  7 06:22:10 2007
From: schwern at pobox.com (Michael G Schwern)
Date: Thu, 06 Sep 2007 22:22:10 -0700
Subject: [tap-l] TAP Datetime discussion
Message-ID: <46E0E002.7020704@pobox.com>

Over on perl-qa we've been discussing the TAP diagnostic syntax as well as a
new proposal for a recommended TAP datetime format.

The thread on TAP diagnostic syntax starts here:
http://www.nntp.perl.org/group/perl.qa/2007/09/msg9084.html

And the proposal itself is here:
http://testanything.org/wiki/index.php/TAP_diagnostic_syntax


The sub-thread about the TAP datetime proposal is here:
http://www.nntp.perl.org/group/perl.qa/2007/09/msg9151.html

And the proposal is here:
http://testanything.org/wiki/index.php/TAP_datetime


-- 
Stabbing you in the face so you don't have to.


From scratchcomputing at gmail.com  Fri Sep  7 18:08:39 2007
From: scratchcomputing at gmail.com (Eric Wilhelm)
Date: Fri, 7 Sep 2007 10:08:39 -0700
Subject: [tap-l] TAP Datetime discussion
In-Reply-To: <46E0E002.7020704@pobox.com>
References: <46E0E002.7020704@pobox.com>
Message-ID: <200709071008.39884.ewilhelm@cpan.org>

# from Michael G Schwern
# on Thursday 06 September 2007 10:22 pm:

>And the proposal is here:
>http://testanything.org/wiki/index.php/TAP_datetime

It's not clear from that what the intended usage of this datetime is.  
It sounds like:

1.  TAP-level metadata (e.g. stream and test start/end times.)
2.  TAP diagnostics.

With #1, it's specified in the grammar.  Thus, the producer and consumer 
have agreed in advance that a given key (e.g. "harness_start_time") 
will be in that format.

But #2 is arbitrary user data.  This means the datetime format has no 
meaning unless it is identified as such.  The example demonstrates this 
weakness:

   not ok 1 - date of the par-tay
     ---
     found:  2007-09-01
     wanted: 2007-09-02
     ...

That's fine if the recommendation pertains to #2 only in terms of making 
dates and times consistently readable for the user.  But, as far as 
parsing is concerned, a datetime stored in an arbitrary key is only a 
string unless it is identified.  If the #2 case intends to be more 
ambitious, some sort of typing is needed.

  !TAP::datetime 2007-09-01

I doubt ^-- that is it.  Maybe just a string "date(2007-09-01)" or 
whatever (or not.)

--Eric
-- 
"Politics is not a bad profession. If you succeed there are many
rewards, if you disgrace yourself you can always write a book."
--Ronald Reagan
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

From schwern at pobox.com  Fri Sep  7 22:22:54 2007
From: schwern at pobox.com (Michael G Schwern)
Date: Fri, 07 Sep 2007 14:22:54 -0700
Subject: [tap-l] TAP Datetime discussion
In-Reply-To: <200709071008.39884.ewilhelm@cpan.org>
References: <46E0E002.7020704@pobox.com> <200709071008.39884.ewilhelm@cpan.org>
Message-ID: <46E1C12E.2070208@pobox.com>

Eric Wilhelm wrote:
>> And the proposal is here:
>> http://testanything.org/wiki/index.php/TAP_datetime
> 
> It's not clear from that what the intended usage of this datetime is.  
> It sounds like:
> 
> 1.  TAP-level metadata (e.g. stream and test start/end times.)
> 2.  TAP diagnostics.

Yep, you've got it.


> With #1, it's specified in the grammar.  Thus, the producer and consumer 
> have agreed in advance that a given key (e.g. "harness_start_time") 
> will be in that format.
> 
> But #2 is arbitrary user data.  This means the datetime format has no 
> meaning unless it is identified as such.  The example demonstrates this 
> weakness:
> 
>    not ok 1 - date of the par-tay
>      ---
>      found:  2007-09-01
>      wanted: 2007-09-02
>      ...
> 
> That's fine if the recommendation pertains to #2 only in terms of making 
> dates and times consistently readable for the user.  But, as far as 
> parsing is concerned, a datetime stored in an arbitrary key is only a 
> string unless it is identified.  If the #2 case intends to be more 
> ambitious

It doesn't, not at this time.  It's just establishing a suggestion for a
particularly common, contentious formatting issue.  Since we need to do it for
the metadata information anyway, might as well throw it out there.


> some sort of typing is needed.
> 
>   !TAP::datetime 2007-09-01
> 
> I doubt ^-- that is it.  Maybe just a string "date(2007-09-01)" or 
> whatever (or not.)

If we wanted to be ambitious we'd write an actual YAML type.


-- 
Stabbing you in the face so you don't have to.

From scratchcomputing at gmail.com  Fri Sep  7 22:39:41 2007
From: scratchcomputing at gmail.com (Eric Wilhelm)
Date: Fri, 7 Sep 2007 14:39:41 -0700
Subject: [tap-l] TAP Datetime discussion
In-Reply-To: <46E1C12E.2070208@pobox.com>
References: <46E0E002.7020704@pobox.com> <200709071008.39884.ewilhelm@cpan.org>
	<46E1C12E.2070208@pobox.com>
Message-ID: <200709071439.41527.ewilhelm@cpan.org>

# from Michael G Schwern
# on Friday 07 September 2007 02:22 pm:

>> That's fine if the recommendation pertains to #2 only in terms of
>> making dates and times consistently readable for the user. ?But, as
>> far as parsing is concerned, a datetime stored in an arbitrary key
>> is only a string unless it is identified. ?If the #2 case intends to
>> be more ambitious
>
>It doesn't, not at this time. ?It's just establishing a suggestion for
> a particularly common, contentious formatting issue. ?Since we need
> to do it for the metadata information anyway, might as well throw it
> out there.

Ok, so this is a REQUIREment for TAP metadata(#1) and a RECOMMENDation 
for usage in diagnostics(#2).  Right?

--Eric
-- 
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

From schwern at pobox.com  Fri Sep  7 23:16:16 2007
From: schwern at pobox.com (Michael G Schwern)
Date: Fri, 07 Sep 2007 15:16:16 -0700
Subject: [tap-l] TAP Datetime discussion
In-Reply-To: <200709071439.41527.ewilhelm@cpan.org>
References: <46E0E002.7020704@pobox.com> <200709071008.39884.ewilhelm@cpan.org>
	<46E1C12E.2070208@pobox.com> <200709071439.41527.ewilhelm@cpan.org>
Message-ID: <46E1CDB0.8070505@pobox.com>

Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Friday 07 September 2007 02:22 pm:
> 
>>> That's fine if the recommendation pertains to #2 only in terms of
>>> making dates and times consistently readable for the user.  But, as
>>> far as parsing is concerned, a datetime stored in an arbitrary key
>>> is only a string unless it is identified.  If the #2 case intends to
>>> be more ambitious
>> It doesn't, not at this time.  It's just establishing a suggestion for
>> a particularly common, contentious formatting issue.  Since we need
>> to do it for the metadata information anyway, might as well throw it
>> out there.
> 
> Ok, so this is a REQUIREment for TAP metadata(#1) and a RECOMMENDation 
> for usage in diagnostics(#2).  Right?

It's now OPTIONAL for diagnostics.  "MAY"


-- 
Stabbing you in the face for your own good.