--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> A see. But TAP isn't SMTP or HTTP and an explicit prefix matches the
> "be descriptive" of Schwern, doesn't it?
>
> And we are talking about the diagnostics part, which is primarily for
> the user, so the rules are reversed there.
There are two g
Michael Peters <[EMAIL PROTECTED]> writes:
> Steffen Schwigon wrote:
>
>> How about reserving a prefix for TAP related keys and allow/ignore
>> everything else?
>>
>> Explained in another way:
>>
>> a prefix lowercased "tap-" for TAP
>>
>
> Thumbs down from me. You don't see HTTP headers havin
Steffen Schwigon wrote:
> How about reserving a prefix for TAP related keys and allow/ignore
> everything else?
>
> Explained in another way:
>
> a prefix lowercased "tap-" for TAP
>
Thumbs down from me. You don't see HTTP headers having to prefix all of their
labels with 'HTTP-' or email he
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Here's the descriptive way to specify how the diagnostic keys work.
>
> 1) We reserve every key which begins with a lower case letter
> 2) We say nothing about anything else
> 3) All keys are optional
How about reserving a prefix for TAP related k
On Apr 11, 2008, at 06:13, Ricardo SIGNES wrote:
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
I thought this had been the resolution. I hope it *is* the formalized
resolution. It is simple and easy and leaves
On Apr 11, 2008, at 03:59, Michael G Schwern wrote:
Quite rapidly everyone shifted over to thinking that we should only
allow
"X-foo" for user keys because it's unambiguous. Then we don't have
to worry
about characters that don't have an up/down-case concept. And we
can eyeball
a user vs
* Michael G Schwern <[EMAIL PROTECTED]> [2008-04-11T07:01:19]
> Here's the descriptive way to specify how the diagnostic keys work.
>
> 1) We reserve every key which begins with a lower case letter
> 2) We say nothing about anything else
> 3) All keys are optional
I thought this had been the re
Here's the descriptive way to specify how the diagnostic keys work.
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
That's it. Remember, the only reason we're saying anything about the keys is
because we want to avo
[For folks who aren't aware, we just had an intense three day hackathon in
Oslo during which about a dozen of us tried to hash out new TAP extensions and
write some sort of well formed spec. We got a lot done, but didn't have quite
the clean resolution I was hoping for. Afterwards I had a number
chromatic wrote:
However, trying to design in sufficient flexibility that the toolset never
needs to be upgraded despite everyone everywhere throwing in new key/value
pairs willy-nilly misses, I think, one very important point:
All* of the TAP I've ever seen has been transient data generated
chromatic wrote:
These are *generated* files. Are you in the practice of checking in generated
files -- and not just files generated deliberately as part of a multi-stage
compilation or deployment process, but files generated as a temporary
byproduct of asking the question "Does the as it exis
Note to TAP folks on perl-qa, please post TAP related stuff to the TAP mailing
list: [EMAIL PROTECTED]
Remember, we're supposed to be encouraging cross-language discussion. It's ok
to CC perl-qa but please make this the primary discussion list for TAP.
--
I am somewhat preoccupied telling the
--- chromatic <[EMAIL PROTECTED]> wrote:
> > > All* of the TAP I've ever seen has been transient data generated
> by
> > > one tool, processed by another tool, and almost immediately
> discarded.
>
> > All of the Java I've ever seen doesn't make use of first class
> > functions and therefore th
13 matches
Mail list logo
