Be library and language agnostic

[jonathanKingston]

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)

[kinow]

+1

[Leont]

Agreed

[jonathanKingston]

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.

[kinow]

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?

[jonathanKingston]

@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)

[Leont]

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.

[kinow]

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

[anko]

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.