David E. Wheeler wrote:
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However, the
first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes.
# from Michael G Schwern
# on Saturday 19 April 2008 08:15:
The prefixing solution sucks, but it's all we have... and that's a bad
place to be. Rather than arguing about a sucky solution, does anyone
have another solution to offer?
I'm not sure what you mean by prefixing[1], or what sucks
# from Eric Wilhelm
# on Saturday 19 April 2008 09:07:
Of course, I would want strict key checking to be off by default and
enabled only by the 'strict' pragma. But conveniently: the pragma is
declared by the tap stream (i.e. emitter.)
And further: strictness must be automatically disabled
On Apr 19, 2008, at 08:15, Michael G Schwern wrote:
#3 is just #2 following an existing cow path. In short, we have a
good idea that official vs user is going to be a problem. Is anyone
arguing it won't? We have a simple, elegant solution to it that
doesn't cause another problem. The
Michael G Schwern writes:
David E. Wheeler wrote:
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in between position is silly and won't make anyone happy.
Yes. The choices, as I see them, are:
1. Do we start
chromatic wrote:
If TAP v15 adds a
new reserved key, anyone who deliberately upgrades may need to modify
both the producer and consumer to deal with the collision, if that person
even cares.
I don't understand. There can be no collision. Official TAP keys all
start with a lower case letter.
--- Michael G Schwern [EMAIL PROTECTED] wrote:
As for why it'll work with TAP, with a few exceptions (exit_status,
or
whatever we decide to call it, is currently the only one), diagnostic
keys do
not effect test parsing. It's not a show stopper. At worst, a
displayer that
has been
On Apr 17, 2008, at 22:44, chromatic wrote:
I don't know how to put this any more clearly, so I'm content to let
this
thread die here and watch TAP v15 careen off into crazy town.
(Alternately,
I could be the one careening off into crazy town, but at the risk of
making
an argument from
On Friday 18 April 2008 10:34:02 David E. Wheeler wrote:
You've convinced me: there should be nothing to distinguish official
from unofficial keys at all, until or unless it actually becomes an
issue.
Funny how this tends to be the opposite of the conclusion that Ovid
draws from your
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However,
the first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes. The choices, as I see
On Wednesday 16 April 2008 22:57:21 David E. Wheeler wrote:
In principal I completely agree with you, chromatic (that is, I agree
with the principal you espouse here; my agreement is not purely
theoretical ;-)). But how does that work in practice? Specifically
with regard to YAML diagnostic
chromatic wrote:
On Wednesday 16 April 2008 22:57:21 David E. Wheeler wrote:
In principal I completely agree with you, chromatic (that is, I agree
with the principal you espouse here; my agreement is not purely
theoretical ;-)). But how does that work in practice? Specifically
with regard to
On Thursday 17 April 2008 15:16:53 Michael G Schwern wrote:
chromatic wrote:
That's my suggestion. Figure out the minimal set of keys that we expect
to use in the near future and reserve those. Document them. Suggest
that we might add more keys later, if there's a rough consensus and
chromatic wrote:
We'd like folks to be able to add their own keys as they need without first
wondering whether it might be useful for others or worrying if we might add
a key of the same name, but different functionality, later. Thus the
separation of local from official keys.
This part I
On Thursday 17 April 2008 16:17:48 Michael G Schwern wrote:
chromatic wrote:
We'd like folks to be able to add their own keys as they need without
first wondering whether it might be useful for others or worrying if we
might add a key of the same name, but different functionality, later.
chromatic wrote:
On Thursday 17 April 2008 16:17:48 Michael G Schwern wrote:
chromatic wrote:
We'd like folks to be able to add their own keys as they need without
first wondering whether it might be useful for others or worrying if we
might add a key of the same name, but different
On Thursday 17 April 2008 17:56:25 Michael G Schwern wrote:
We're working around the same issue Perl 5 is having adding new keywords.
In Perl 5, since keywords and user-defined subroutines share the same
space, we can't add a new keyword without risking clashing with a
user-defined
Executive summary: User key collision is not a show stopper.
chromatic wrote:
On Thursday 17 April 2008 17:56:25 Michael G Schwern wrote:
We're working around the same issue Perl 5 is having adding new keywords.
In Perl 5, since keywords and user-defined subroutines share the same
space,
On Thursday 17 April 2008 19:10:21 Michael G Schwern wrote:
As for why it'll work with TAP, with a few exceptions (exit_status, or
whatever we decide to call it, is currently the only one), diagnostic keys
do not effect test parsing. It's not a show stopper. At worst, a
displayer that has
chromatic wrote:
On Thursday 17 April 2008 19:10:21 Michael G Schwern wrote:
As for why it'll work with TAP, with a few exceptions (exit_status, or
whatever we decide to call it, is currently the only one), diagnostic keys
do not effect test parsing. It's not a show stopper. At worst, a
On Thursday 17 April 2008 20:21:52 Michael G Schwern wrote:
chromatic wrote:
If TAP v15 adds a
new reserved key, anyone who deliberately upgrades may need to modify
both the producer and consumer to deal with the collision, if that person
even cares.
I don't understand. There can be
On Apr 13, 2008, at 15:58, chromatic wrote:
The problem with an infinitely expandable protocol that tries to do
everything
is that it's infinitely expandable and tries to do everything.
Might be nice
to rein that in a little bit more. Or don't, and instead make it
trivial to
add ad-hoc
Ovid [EMAIL PROTECTED] writes:
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
Then maybe I haven't understood what the standardization of
diagnostics is about.
I thought it is primarily meant for the *user* of TAP to transport
its own diagnostics of its own test runs and test results?
I
Michael G Schwern [EMAIL PROTECTED] writes:
Ovid wrote:
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we want:
1. Make it as human-readable as possible.
2.
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
Then maybe I haven't understood what the standardization of
diagnostics is about.
I thought it is primarily meant for the *user* of TAP to transport
its own diagnostics of its own test runs and test results?
I for instance would use it to
Ovid wrote:
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we want:
1. Make it as human-readable as possible.
2. Maximize flexibility.
As for human-readable,
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
B) Reserve lower case and
On Sun, 13 Apr 2008 18:41:04 +0100
Michael G Schwern [EMAIL PROTECTED] wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but I'm
worried it's carving out too small a space.
B) Reserve lower case and leave the spec a little fuzzy around the
David E. Wheeler wrote:
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but I'm
worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
I
On Apr 13, 2008, at 11:37, Michael G Schwern wrote:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can
use.
I don't have any particular reason. Just a feeling
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
Remember, the producer and the displayer of the non-reserved keys are both
under local user control. They choose the custom keys and they choose what
they need and can handle.
That sort of eliminates the upgrading problem, doesn't it?
chromatic wrote:
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
Remember, the producer and the displayer of the non-reserved keys are both
under local user control. They choose the custom keys and they choose what
they need and can handle.
That sort of eliminates the upgrading
On Sunday 13 April 2008 14:58:33 Michael G Schwern wrote:
chromatic wrote:
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
Remember, the producer and the displayer of the non-reserved keys are
both under local user control. They choose the custom keys and they
choose what
On Sun, Apr 13, 2008 at 03:58:58PM -0700, chromatic wrote:
and you'll end up with the protocol equivalent of spaghetti. Anyone care to
guess how many X-* headers there are in all of the SMTP clients and servers
in the wild? How about HTTP headers? Maybe you don't have to care about
$
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 keys
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 headers
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 having to prefix all
of
--- 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 goals we
38 matches
Mail list logo
