TAP V1.0: Request for Comments

This document will act as RFC centre for the TAP V1.0 Proposed Recommendation.

Review period: 2009 July 10 – 2009 August 21 (6 weeks)

In order to add a comment to the document, please edit this page and add your comment to the list below (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussions about any of the comments or responses should be conducted on the DAL mailing list, dal@ivoa.net.

Comments from the community

• Sample comment by WikiName
  • Response (by WikiName)

• May I once more request that the note in 2.3.4 recommends an empty string as the system when columns references are used and tells the system to insert the system actually used? Without this, it becomes virtually impossible to write spatial queries running on services using different coordinate systems (this would require an editorial change in the paragraph above to allow an empty string in addition to STC's reference frames. -- MarkusDemleitner

• Isn't there a requirement for implementations or prototypes before a standard can go to RFC? Please can somebody post the service URLs of these, so that I can try out TAP for real? -- Roy Williams

• Comment by TomMcGlynn

It appears that the appearance of a formal RFC has frozen comments on TAP except for Roy's question. So let me try to restart things...

First, it seems like there was quite a bit of discussion of TAP ongoing at the time this RFC was started. I think it would have been desirable to write another draft attempting to accommodate the ongoing discussion before the RFC, but perhaps that was not possible.

Second: I've submitted two sets of detailed comments in the DAL list. I don't intend to repeat all of them here, but I would like to reiterate the overarching theme of many of both the substantive and editorial concepts: the TAP standard should be disentangled from the HTTP standards it is built upon. E.g., editorially TAP should say that it uses the standard HTTP conventions for keyword names and values but the current example practice where we use pseudo (i.e., improperly encoded) URL fragments is confusing and wrong. It's not the case that parameters are necessarily joined using &'s. Any Web page is free to use the Multi-part mime-type encoding even if it does not upload files. This is a detail of the HTTP implementation that TAP should not expose.

The major substantive change that I (strongly) suggest -- that we not tie the idea of file uploads to a particular kind of HTTP parameter but simply establish a keyword namespace (or namespaces) for file uploads -- similarly distinguishes TAP and HTTP. TAP should use the abstraction of keyword/value pairs from the HTTP standard. If it is properly layered on top of HTTP, it does not worry about the details of how these are encoded -- that's outside of its purview. So if a keyword happens to be in the table upload name space, then the value of that keyword is a table upload -- regardless of its encoding. In practice that will likely use a <input type=file> entry on some Web form. But there is nothing gained by our mandating that any such data is a table upload -- and very significant cost. For instance we preclude file uploads being used compatibly for any other purpose

I have no problem with a non-normative appendix discussing HTTP and giving examples of how TAP requests might be sent over it.

• Comments on Chapter 2, sent to dal mailing list, 12/08/09, by AlbertoMicol

issues from the mailing list just before and during the RFC period, 2009-08-28, collated here by PatrickDowler

0. purely editorial issues not listed here

1. sec 2.3.6 arbitrarily limits the VOTable to TABLEDATA format

assessment: minor change to remove limitation

2. sec 2.2.2 says "single result" and 2.7.1 says "single table"

assessment: minor change to clarify that the query language dictates how many "tables" are produced by a single query; SQL-based languages like ADQL produce a single table

3. sec 2.3.4 specifies the ISO8601 timestamp format without the T separating the date and time parts

note: testing showed that some RDBMSs cannot parse the format with embedded T, but T is used elsewhere in IVOA

assessment: minor change to require the T; imposes possible work on implementors

4. sec 2.3.8 describes the MTIME request attribute which filters the rows returned from a query, but support is optional so this could be very dangerous

note: MTIME is intended to be used in conjunction with MAXREC to harvest content from one service to another, eg for indexing/search engine purposes, already appears in SSA. It seems poorly understood in the TAP context and can be complex underneath... also worries people when mixed with the concept that unsupported request params like MTIME can be silently ignored, leading to large (MAXREC) query results. MAXREC does protect both service and client worst case.

assessment: hard to fix (fully specify) at this time; we could specify that queries fail if MTIME is used and not supported (rather than ignored), clarify as much as possible, and promise to release a Note about implementing and using it later... or we could drop it from 1.0 and worry about it again for 1.1

5. sec 2.5 specifies use of xtype="adql:POINT" or xtype="adql:REGION" rather than using xtype='STC-S" from the VOTable 1.2 doc

note: ADQL treats point and region slightly differently in a few places and both were recognised as necessary data types; for better interroperability between services, something like xtype="stc:AstroCoords" or xtype="stc:Region" and xtype="stc:ISOTime" would be better and we would have to VOTable-specific or TAP-specific xtypes.... assuming one can extract suitable type-names from STC.

assessment: need the distinction, cannot use only VOTable values

6. the static resource structure specified by TAP is rigid

assessment: substantial change at this time since we do not have defined capabilities to describe the URLs for these endpoints (see #8)

7. inline table upload uses en element name as the intended (destination) table name and as specified too tightly coupled with http (also from Tom's comments above)

note: has inline table upload been implemented in any prototype? is it proven to work or proven to not work? given that uploads have to be VOTable, is this really usable as is anyway? it does avoid the need for a server (http, eg) to serve the uploaded table

assessment: substantial change to fix if the current draft is unworkable...

8. VOSI requests are done via the REQUEST parameter and the sync endpoint rather than plain resources off the base URL of the service, thus entangling the mandatory support for sync (and async) with the location of the VOSI requests... proposal was to access VOSI via resources, make both sync and async optional (must have one, of course), and describe the presence and location of sync and async endpoints via capabilities (thus also relieving part of #6 above)

note: inconsistent with DAL style as specified in SSA 1, consistent with REST and GWS style as expressed in the VOSpace 2.0 draft

assessment: modest work to change VOSI to resources from REQUEST(s), substantial change to make sync and async optional and define capabilities to describe them, but then we get the flexibility asked for in #6 for free

• Comment by AlbertoMicol on the spatial query support.

Par. 2.3.4 states that:

if the tables[...] contain [...] spatial coordinates 
and the services support spatial querying via the ADQL region construct,
(then) the service MUST support INTERSECTS [...], REGION, POINT, BOX [...]

I would claim useful if the overall philosophy on how to construct a query (first access the metadata, to gather column names, units, etc, then formulate a query) could be highlighted in the introduction.

I would claim very useful for data providers' uptake if tutorials could be provided on various aspects, for example:

• tutorial (or just more extensive examples) on ADQL usage (including regions, utypes, etc),
• tutorial on how to publish a TAP service in the registry (including real examples on all VOSI interfaces, etc.)

* comment on TAP_SCHEMA by PatrickDowler

The TAP_SCHEMA.columns table has a column named primary, but primary is a reserved word in (I expect) most databases since it is used to declare primary keys. ... upon reflection and discussion, the concept is useful for users and client software to help make exploratory queries that see the important columns. We just need to change the name.

* comment on the single table output by FrancoisBonnarel

I understood from July discussion that the idea to be able to get more than one table in the output is strongly out of the scope for many of the participants of this discussion including the main designers of the TAP protocol, for the reason they gave in the discussion (see Dal mailing list / July). But anyway, let me reask it with my CDS-oriented view:

If your model has a strong OO structure your dataset/catalog will be structured with several tables of very differents sizes/structure.

If you want to query that in TAP, you will have either to do HUGE jointures, or to make the query in several steps (one for the "main" table, one to several for additional information related to the main one by a common key. None of these solutions are totally satisfactory.

Examples are: Vizier, where many catalogues have a main table and auxiliary ones. Simbad where each object have Data sections of very heterogeneous sizes. The future Generic Data Set where primary information would have to be linked some day to AccesData features, Full ObservationDM metadata, Type oriented DAL services, etc

Would it not be possible to define a parameter allowing a multi table output when it is set to TRUE ? Standard TAP queries will use by default "FALSE", and everybody could be happy?

* Comment by TomMcGlynn [This is submitted long after the RFC, but it seemed reasonable that this should be included here so that users need not scurry to find them in the DAL mailing lists. TAM - 2009-10-09.]

• The types of columns in the TAP schema are required to be variable length strings, even those which have boolean or integer values. The strings to be used when representing a boolean are not specified. Discussion on the DAL has suggested that the types of several columns in the TAP Schema will be changed.
• There is no description of the capabilities record that is to be returned by a TAP service in the VOSI getCapabilities. The DAL discussion seems to indicate that defining that is a significant task but how a service is to implement this required capability is not clear.

Comments from the TCG during the normal RFC period (2009 July 10 -- 2009 August 21)

Applications (Tom McGlynn, Mark Taylor)

See comments above (TAM)

Data Access Layer (Keith Noddle, Jesus Salgado)

Data Model (Mireille Louys, AnitaRichards)

Grid&Web Sevices (Matthew Graham, Paul Harrison)

Registry (Ray Plante, Aurelien Stebe)

Semantics (Sebastien Derriere, Norman Gray)

VOEvent (Rob Seaman, Alasdair Allan)

VO Query Language (Pedro Osuna, Yuji Shirasaki)

VOTable (Francois Ochsenbein, 2009-09-25)

1. possibility of having full VOTable documents as results / for uploads (not limited to a single TABLEDATA table); items 1+2 of Pat's summary, but also the table upload (sec. 2.5). For the VOTable output, Pat's proposal (actual number of tables depends on the query language) looks fine. The table upload is not yet fully defined, clarifications are neeeded.
2. the MTIME concerns (item 4 in Pat's summary): the proposal to drop this for V1.0 is quite ok for me;
3. the xtype definition and scope (item 5 in Pat's summary): needs clarification and agreement with VOTable standard; Pat's proposal looks like a duplication of the utype which I would prefer to avoid. The role of xtype and its relation with the query language has to be clarified.

Standard and Processes (Francoise Genova)

Astro RG (Masatoshi Ohishi)

Data Curation & Preservation (Bob Hanisch)

Theory (Herve Wozniak, Claudio Gheller)

TCG (ChristopheArviset, Severin Gaudet)

Comments from the TCG (2009 October 09 -- 2009 November 06)

Note: A revised PR-TAP-1.0 document, taking into account the above issues and subsequent mailing list discussions, is now available from the documents page: PR-TAP-1.0-20091006

Note: something odd happened during html export that put odd characters in various places; will fix so no need to report on that; the PDF should be ok.

Applications (Tom McGlynn, Mark Taylor)

This document clearly defines a core functionality for generic queries of tables using either ADQL and PQL. This functionality is central to the development of VO applications and with this document as a guide both data providers and data clients should be able to build very powerful services using these core capabilities. Promoting this document to a recommendation should encourage the widespread adoption of the core TAP functionality leading to an immense increase in the fundamental capabilities of the VO.

The TAP interface is very complex with with strong interactions with a myriad of other VO protocols. A number of issues in ancillary areas have arisen since the release of the RFC, in TAP metadata, table uploads, VOSI capabilities, version negotiation, geometry support, and the interfaces of TAP to W3C and other IVOA protocols. A few of these have been addressed in changes made to the document between RFC and TCG review. It is unclear if substantive changes of this kind were appropriate at that point, since they were not themselves subject to general review. Overall these issues raise doubts that this document is an adequate guide to building a fully conformant TAP implementation.

Given the juxtaposition of these opportunities and concerns, Applications abstains in the approval process, with a recommendation that, regardless of the outcome of this process, work begin immediately on a new version of the document which focuses not on new functionality but on a clarification and resolution of issues in these ancillary areas.

Data Access Layer (Keith Noddle, Jesus Salgado)

Data Model (Mireille Louys, AnitaRichards)

Grid&Web Sevices (Matthew Graham, Paul Harrison)

Registry (Ray Plante, Aurelien Stebe)

I have two TCG-level comments:

• Section 2.9 indicates that TAP requires the use of VOTable 1.2 or greater. Section 2.9.1 specifically talks about use of the INFO element based on the pre-TCG-reviewed version of VOTable 1.2. Subsequently the definition of the INFO element changed, so Section 2.9.1, including all examples need to be updated for this change.

• As has been pointed out in the mailing list, the description of VOSI outputs (section 2.7.2) is still a bit too vague; it is not clear exactly what should be returned. Part of the problem is that we have not yet defined a TAP-specific capability extension; however, my sense is that we will not want to delay the TAP spec to figure this out. Taking this into account, I have posted to the DAL list (dal/0910/1620.htm) some additional suggested text that could be put into this section to clarify what needs to be returned. Probably of most practical importance, an example is included.

Semantics (Sebastien Derriere, Norman Gray)

Comments from NormanGray. There are minimal interactions with the Semantics WG, so the following are comments on exposition and the document itself. I haven't worked through the various comments above, so some of these might be duplicates.

Hrumph. I was looking at the 2009 June 7 version of the document. It might be useful to put a link to the current version of the document in the first line of this page, and not a four-month old version. It's not clear to me, therefore, how many of the comments below are still useful.

Document as a whole:

• The document TITLE element is still given as 'IVOA Document Template'
• The document character set is wrong. It's served as ISO-8859-1, but contains UTF-8 characters (most noticeably double-quote characters, but also, in sect 2.4, some characters in code examples). One option would be to serve the document as UTF-8, but Bruno has said that's problematic, so the document should either be transcoded to 8859-1 or the problematic characters converted to entities.
• The page numbers in the table of contents make no sense in an HTML document, and would be misleadingly wrong if the document were printed out.
• There are several errors in references -- I didn't check all the cross references.

1 Introduction: ADQL and PQL are mentioned. It would be useful to have references to the relevant Recommendations.

1.1.3 VOSI: "specifies base service interface" should be "specifies a base service interface"

1.2.2 Synchronous queries: "Metadata queries are always executed synchronously". Is this a MUST. If so, it might be better documented as such in s1.1.2, which should include a cross-reference to where the metadata queries are more fully documented.

1.3 Interface overview (informative): Footnote 2 is redundant, given the discussion of the 303 See Other response later in this section. Also, this section doesn't seem notably more 'informative' than the presumably normative subsections earlier in this section.

2.2.2 /async: There's a reference to UWS, and reference [5]. However, reference [5] is to RFC2396. I haven't bothered checking other references and cross-references -- they're surely automatically generated and this error was just a glitch.

2.3.3 LANG: "The service should return an 'unknown query language' as described in 2.9" -- perhaps "return an 'unknown query language' error...". This section refers to "the subsequent query parameter(s)". However as noted in s2.1.12, the parameters can come in any order. Perhaps "the other query parameter(s)" would be better.

2.3.4 Query: The quoted "yyyy-MM-dd[ HH:mm:ss[.SSS]]" is not a legal ISO-8601 datetime format. If the included space in that string is deliberate, it's not part of an ISO-8601 datetime spec, but indicates a separate date and time specification. In any case, the more restricted format of RFC3339 or <http://www.w3.org/TR/NOTE-datetime> would make better specs: both agree that yyyy-mm-dd[Thh:mm:ss[.ss]] is a suitable time. The same is true in s2.3.5 (the TIME=... example has a correctly-formatted time, though with a trailing slash). Note that since this syntax doesn't include a possible time zone or UTC offset, it presumably requires that everything be in UTC -- it would be good to make that explicit.

2.3.6 FORMAT: MIME type strings are case-insensitive, too, according to RFC2045 (ie, APPLICATION/x-VOTable+XmL is a VOTable MIME type). Well, RFC2045 specifies that the Content-Type header's values are case-insensitive, but I think this can be taken to imply that MIME types are always case-insensitive.

2.3.8 MTIME: There are multiple ISO-8601 range list formats -- do you really want to require TAP services to have to support "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"? Neither RFC3339 nor the W3C datetime note include ranges -- perhaps the best thing here would be to declare that the MTIME parameter format must be a pair of ISO-8601 instants separated by a slash (that's one of the legal ISO-8601 formats). Also (picky), this section doesn't indicate whether the time interval is open or closed (I'd suggest inclusive at the start, and exclusive at the end, of the interval).

2.5 Table Upload: there's no discussion of authentication and authorisation here. I presume that's been taken care of elsewhere, in which case a reference to that would probably be useful here.

2.5.2 Inline Table Upload: A reference to RFC2046 and RFC2388 would be useful here

2.7.1 Data and metadata queries: refers to the TSV spec as [15], when it should be [16]. This mentions "Column values may not contain the TAB character" -- this should be "must not", since "may not" is ambiguous between "must not" and "might not".

2.7.3 Errors: This section is terribly vague. If I were implementing a TAP client, I wouldn't have a clue what to expect here -- all it seems to say is that I'll get an HTTP status returned within the HTTP request! Providing a 200 (OK) response with an error document seems ... eccentric, when there are plenty of sensible alternatives in the HTTP speec (I know SOAP does this, but that can hardly be said to be an argument in favour).

2.8.2 Version number changes: paragraph one says "no more than two integers", whereas paragraph two talks of "[a] version number change at the third level". Also the paragraph one text permits a single integer ("no more than two"). Which is it? One, two or three integers?

2.9.2 Version mismatch errors: these are signalled by an "ERROR" in an info element. That seems a bit non-specific. Wouldn't a more specific error code be useful.

4 Extended capabilities: there seems to be no way of registering extension names, even implicitly with, say, a reversed domain name. In a standard for networked operations, this seems to be asking for trouble.

7.1.1 Introduction: RFC2616 defines the 'http' scheme, but (as noted in s7.1.2) it's RFC2396 which defines URIs.

8 References: Not all of the linked URLs are clickable. For example, the VOSI URL doesn't work -- whatever it is that's converted this to HTML has simply coloured this text blue!

VOSI is included in the reference list twice, as [6] and [14]. Note that VOSI is still a WD, not a Rec (can I insert my standard moan about this?) Reference [15] refers to "EITF", should be "IETF"

VOEvent (Rob Seaman, Alasdair Allan)

VO Query Language (Pedro Osuna, Yuji Shirasaki)

VOTable (Francois Ochsenbein)

• Two comments related to VOTable:
  1. Sorry for the changes in VOTable <INFO> tag, which was changed following the comments during RFC to ensure compatibility with previous versions; as pointed out by Ray, the examples should be corrected (<DESCRIPTION> and </DESCRIPTION> should be removed)
  2. the FORMAT parameter (section 2.3.6): is there any relation with the possible serialisations in VOTable (<TABLEDATA> in 'pure' xml, <FITS> and <BINARY>) ? Would it mean that, if application/x-votable+xml is specified, that the <BINARY> serialisation is acceptable ? Or is there any means of specifying which serialisation the client would prefer ? It can make a huge difference for an application processing many huge TAP outputs

• One comment related to the TAP_SCHEMA: the indexing description still seems to be incomplete, the order of columns in a multi-column index should be specified somewhere, and the unicity of an index is an important feature not described. Anyway I still feel that describing completely the indexes is not relevant for TAP -- just the flag specifying that a column is indexed (or is the first column used in a multi-column index) is enough. It would be more important to describe the keys (which combination(s) of columns define uniquely a row)

• My last comment is related to the specification of errors/overflows (sections 2.7.3 and 2.7.4): I feel it's dangerous to have no method to specify an error or an overflow in non-VOTable output. Isn't it possible to imagine some way of giving this information for other output formats than VOTable ?

Provided these questions are sorted out, I would be happy to approve the document.

Standard and Processes (Francoise Genova)

Astro RG (Masatoshi Ohishi)

I can go along with the document after the suggested changes have been fixed. Let us have the TAP v1.0 as soon as possible.

Data Curation & Preservation (Bob Hanisch)

These comments are mostly presentation details which are easily fixed, however there are a couple of issues of substance. None of these are show-stoppers in my view, however, and I would be ok going ahead to REC if things are tidied up. Another option would be to hold TAP at PR for a period of time so that we could see a larger number of fully functional, interoperable implementations, and get further feedback from implementers regarding where the specification needs more detail.

The labels “normative” and “informative” do not seem to be applied consistently. Only Section 1.4 of the Introduction, for example, is labeled “informative”, but it seems appropriate that all of Section 1 be labeled “informative”. On the other hand, Section 7 has the “must” and “should” language of a standard and would seem to be “normative”. If the point is to recap HTTP rules then it might be better to move this to an Appendix (e.g., content that is explicitly informative) so it is clearer that these rules are about HTTP and not about TAP.

Section 1, para 1, both ADQL and PQL should have references here, on their first occurrence in the document.

Para 2, “or in some other format” would imply that virtually anything is ok. Better would be something like “or in one of several other formats specified herein.”

Section 1.1, sentence is missing an “and” after “metadata queries”.

Section 1.1.2, first sentence has awkward phrasing in “a subset and patterned after”. Perhaps “...to standardized tables that are a subset of, and patterned after, information schema in RDBMSs...”

Section 1.1.3, first sentence needs to be with “The” and another “the” is needed before “base service”.

In last sentence, “IVOA registry” needs a reference.

Section 1.2.1, “...will not be usable with other services unless they implement the exact same data model.” This does not seem correct to me. Isn’t the point that the data models need to be sufficiently similar that like elements are comparable? For example, one could certainly compare two TAP services with very diverse contents if both provided the same contents in the area of interest to the user. So I would have said “a sufficiently similar data model” or something along those lines.

Section 1.2.2, I am not sure that “PQL is more abstract than ADQL” (actually I might have said ADQL is more abstract than PQL), but it really doesn't matter. I would drop this phrase and just have “PQL can be used in some cases without first querying the metadata tables; PQL parameters carry sufficient meaning to enable...”.

In last sentence, it should be “Details...are...”

Section 1.3.2, last sentence, insert “are” before “likely to fail”.

Section 1.4, first sentence needs “The” at the beginning.

Footnote 2 ends with “(see other)”. See other what? Actually, I know that this means that HTTP code 303 stands for “see other”, so it is just the parentheses that make this a little confusing. Writing “HTTP code 303: See Other” would solve the problem.

Section 2.2, reference [5] at end of 1st para should be [3]

The list of UWS resources is not completely consistent with the UWS specification. In particular, UWS does not define a “termination” URI, and the URI is “parameters”, not “param”.

Section 2.3, last sentence, I would have thought that a response to a spurious parameter should at least include a warning rather than being completely ignored.

Section 2.3.1, 3rd para, “This is...” should be “These are...” as it us referring to “additional parameters”.

Section 2.3.3, “...is ADQL...” should be “...are ADQL...”. The parenthetic descriptions of ADQL and PQL are unnecessary here, as this has been said elsewhere.

Section 2.3.4, 4th para, “...and the services supports...” should be “...and the service supports...”

Section 2.3.5, 1st para, “...are specified in elsewhere...” ???

3rd para, “...and the services wants...” should be “...and the service wants...”

End of 4th para, suggest rewriting as “Details on how to use table references in PQL are given in the PQL specification document. [ref]”

Section 2.3.7, 2nd para, “This value” should not be in italics.

Section 2.3.9, “(e.g., scheme is vos or param)” I think needs to be clarified

Section 2.5, 3rd sentence, missing “the” before “uploaded table” and missing “a” before “legal ADQL table”.

Section 2.5.2, 1st sentence, missing “the” before “caller” In the example, this reader does not grasp the “boundary=AaB03” stuff. Is this obvious to others?

Section 2.6, the 1st sentences seems to go around in circles. In skeleton form: “The [] schema defines tables in the SCHEMA schema that contain [] metadata required to use the tables...”. At some level I think it makes sense, but I’m hoping that this can be reworked!

Section 2.6.1, “The schema_name values are unique.” Unique within what scope? How is this to be enforced? I have the same question regarding the definition/scope of “unique” in 2.6.2. 2.6.3, and 2.6.4.

Section 2.6.3, column_name unit, cites “VO standard format”. We don’t actually have an explicit document on standard units. VOTable refers to SI units and FITS conventions. I think this needs a footnote or something to explain the situation.

Section 2.6.4, there is a block of text starting with “Data types and how they map...” which seems out of place here, as this is not to do with Foreign Keys. Does this belong in the general text of 2.6 at the beginning?

In the middle of this paragraph “...where the services chose...” should be “...where the service selects..”, and “...which columns are returned by default” would be better as “...those columns that are returned by default.”

Section 2.7.3, after bullets, “...service containers an cannot...” should be “...service containers and cannot...”

Section 2.8.1, remove hyphen in “version-number” and add reference after last sentence (to IVOA document conventions).

Section 2.8.3, what is meant by “...level two”?

Section 3, 5th paragraph, “The resource document should include the table metadata...”. I think this is getting a bit far afield from TAP and straying into best practices for registries. I’d rather the “should” were a “may”. The footnote (6) is very wishy-washy and I think can be deleted.

Section 5.1 and 5.2, there are several places where there is extraneous space in the example HTTP GET and POST commands, particularly “/tap /sync/”

In 5.1, as noted before, the UWS resources are not totally consistent with the UWS specification.

In the middle of this section, the sentence that begins “Practically, ...” is a very odd structure. I don’t think one typically starts a sentence with an adverb like that. It would be better as “In practice it is very hard...”.

Section 6, rather than “prototyping” I’d suggest “further implementation experience”.

Theory (Herve Wozniak, Claudio Gheller)

TCG (ChristopheArviset, Severin Gaudet)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->