# 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
---------------------------------------------------
