Specification icon indicating copy to clipboard operation
Specification copied to clipboard
verified publisher icon TestAnything

Be library and language agnostic

Open jonathanKingston opened this issue 10 years ago • 8 comments

To make the format have a wider appeal all specific mentions to libraries should be removed from the specification.

  • Code samples if any are worth keeping should be provided in several differing languages (Perhaps pick Perl, Java and JavaScript as a slice across what is most useful in differing areas)

jonathanKingston avatar Jan 06 '15 21:01 jonathanKingston

+1

kinow avatar Jan 06 '15 21:01 kinow

Agreed

Leont avatar Jan 13 '15 22:01 Leont

Can we agree upon good languages that are good demonstrators within the documentation?

There are a lot to choose from and I would like not to have too many within the specification itself.

I would also like to see EBNF and/or similar as the primary for examples.

jonathanKingston avatar Jan 13 '15 23:01 jonathanKingston

I can help with Java, though I think that's not the best language for documentation. Maybe as in the SPARQL specification, just use simple TAP examples, EBNF (+1 from me for this, or similar) and provide links to existing implementations in Python, Perl and maaaaybe Java. The most important thing is that these implementations adhere to what we want to demonstrate. What do you think?

kinow avatar Jan 13 '15 23:01 kinow

@kinow certainly that appears to be the direction of others. Perhaps code samples can be supported by the site itself.

Regex samples worth having within the document?

BNF, EBNF or ABNF? (I'm slightly erring towards ABNF at the moment as appears to be used more in RFC's)

jonathanKingston avatar Jan 14 '15 00:01 jonathanKingston

The earlier draft contains an ABNF, but is describes only TAP12 plus the version header. No subtests, extended information or pragmas. Doesn't seem unicode friendly either.

Leont avatar Jan 14 '15 00:01 Leont

I'm thinking about using some spare time in March to give it another try at rewriting the tap4j parser with JavaCC. When doing that I can review any existing draft for TAP 14, or propose something

kinow avatar Jan 25 '15 22:01 kinow

I think code implementing a spec doesn't belong in a spec. Reasons:

  • It's impossible to choose languages that represent the full breadth of programming languages well. (Many paradigms exist.)
  • If this spec is still in use in 10 years, current languages/paradigms may be dead.
  • Separation of concerns: Let's let implementations worry about implementations.

I'm all for a reference implementation in a currently popular language though.

anko avatar Mar 20 '15 01:03 anko