Subject: Re: [tap] TAP Diagnostics

From: Eric Wilhelm <[email-masked]>
Date: Thu, 21 Aug 2008 11:04:11 -0700

# from Ricardo SIGNES
# on Thursday 21 August 2008 09:57:

>> Does it have to be just one?  Now and forever?
>
>Some people want the spec to say that diagnostics (not free-form
> additional data blocks) are always readable by any TAP consumer,
> which means they need a declared format.  It needs to be at least one
> declared format.

How about if the diagnostic is a free-form data block with a format 
identifier?  Then the JSON/YAML diagnostic is just a special case, 
where support for one or both of those could be required/recommended.

>Schwern would like it to be YAML (a superset of JSON), with the
> phrasing "consumers MUST understand JSON and SHOULD understand YAML."

Does that work?  If a JSON parser is handed linewise YAML, doesn't the 
consumer just trip all over itself?

So, you have to identify the format of the data block anyway, right?

# from Ovid on Thursday 21 August 2008 10:20:
>I originally argued that we should allow more than one, but I was
> wrong.  We don't know the source of our TAP and if everybody and
> their dog is speaking a different diagnostic language, we may as well
> junk diagnostics ...

What I'm suggesting is to require the consumer to support one diagnostic 
format, but define the data block and identifiers in such a way that 
additional formats MAY be supported by the consumer.

  not ok 42
    --- diagnostic: JSON/4627
      {"want": 18, "have": 40}
    ...
  ok 43

  not ok 42
    --- diagnostic: YAML/1.2
      want: 18
      have: 40
    ...
  ok 43

So, non-diagnostic data blocks might be "--- data: $whatever" or 
something?

But this raises the question of:  what does it mean for a consumer 
to "understand" the diagnostic?  How far down into the content 
(keys/values) of the diagnostic does the TAP spec want to go?  What is 
the consumer going to *do* with this information?  If the TAP protocol 
is simply a matter of reliably communicating the diagnostic info to the 
consumer (and associating it with a result?), does specifying the 
consumer's usage of the diagnostics over-reach?

--Eric
-- 
Entia non sunt multiplicanda praeter necessitatem.
--Occam's Razor
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
tap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tap

---

From: Ricardo SIGNES <[email-masked]>
Date: Thu, 21 Aug 2008 16:43:40 -0400

* Eric Wilhelm <[email-masked]> [2008-08-21T14:04:11]
> consumer just trip all over itself?

Correct.

> So, you have to identify the format of the data block anyway, right?

Sure seems that way.

What Ovid and I had discussed in Oslo was that consumers would have to parse
fullYAML, because of this very problem.

I'd still rather have Just JSON for this...

>     --- diagnostic: JSON/4627

Yes, I am in favor of this.  I'd just use MIME types, though.  text/json,
application/x-yaml, whatever.

Anyway, then you can say that the only thing consumers must understand is JSON,
because that will be used for the core diagnostics: wanthave, line, etc.

I think it's useful if there is a common ground, where even if TAP Consumer A
doesn't know how to /really/ understand the havewant emitted by some foreign
producer, it can at least compare them /qua javascript/ and show how they
differ.  It's better than nothing... probably.

My real concern is avoiding tying TAP to YAML.  Tying TAP to JSON is, in my
mind, not a problem at all, *if we need a common dialect for simple structured
data*.

-- 
rjbs

---

From: Eric Wilhelm <[email-masked]>
Date: Thu, 21 Aug 2008 15:07:38 -0700

# from Ricardo SIGNES
# on Thursday 21 August 2008 13:43:

>Yes, I am in favor of this.  I'd just use MIME types, though.
>  text/json, application/x-yaml, whatever.

Sure, I had thought about that.  The block's content has to contain 
anything related to a version bump in the format?

--Eric
-- 
Consumers want choice, consumers want openness.
--Rob Glaser

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Fri, 22 Aug 2008 04:52:28 +0200

> Does it have to be just one? Now and forever?

It doesn’t have to be *just* one, but it needs to be *at least*
one, and specifically at least one that *everyone* supports, so
that you can count on having a way to make an emitter and
consumer understand each other.

The question that arises is that since everyone has to support
that particular format, how much value do we gain from letting
people use other ones?

Personally I am not sufficiently convinced that allowing for more
than one format will turn out to be harmful that I would argue
against it, but I am also quite unconvinced of the value, and I
do know that this flexibility will incur costs.

So I am inclined to say that it should probably be just one
format, now and forever. (If worst comes to worst we still have
the very-last-resort option of revving TAP.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
tap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tap

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Fri, 22 Aug 2008 05:02:35 +0200

* Ricardo SIGNES <[email-masked]> [2008-08-21 19:00]:
> Ovid (and I) would like it to be JSON, pending any better idea
> (that we agree is better).

FWIW, after some consideration, I find myself drifting toward
the JSON camp as well. It’s a slow drift, but I just can’t help
disliking YAML for making the ultimate mockery of its own initial
design goals. (You have no idea how much regret-on-someone-
else’s-behalf this has caused me. I would love to be able to like
YAML.)
 
> phrasing "consumers MUST understand JSON and SHOULD understand

I could arrange myself with Schwern’s desire, so long as we could
agree to make that SHOULD a MAY. That would in fact work very
well for me.

Regards,