an analogy

[Robert Hanisch]

Dear DAL/TAP folks,

  There seems to be a real band-wagon effect going on here, toward this idea
of separating ParamQuery from the main body of the TAP specification.  On
the surface I see why people might see this as elegant or clean.  In
practice I think it is unnecessary and actually makes a bigger mountain from
a mole hill.

  I've gone through 0.30 and 0.31 of TAP again.   Both are in need of some
further reorganization -- thinking in terms of an implementer, neither is
really optimized in terms of presenting what one really needs to know in a
very logical way.

  However, the ParamQuery part of the spec -- the part that is really
specific to the query itself -- comprises about 5 pages of text (of a
40-page document).  The relevant parameters are POS, SIZE, REGION, SELECT,
FROM, and WHERE.  Of these, SELECT, FROM, and WHERE, which take 3.5 pages of
text, are quite unique to TAP.  So it is hard to see any great benefit in
moving the definitions of PQ out to another document.  Doing so, in fact,
means that we have to turn the review and approval gear set for that
document as well as the main one, and to what real purpose?

  Much of the TAP I/f definition is about parameters in any case.  QUERY,
LANG, FORMAT, UPLOAD, MAXREC, MTIME, RUNID.  ParamQuery is an extension of
the parameter set for simple queries.  The rest are all HTTP params, and the
only distinction is whether the query is carried in the text value of the
QUERY parameter or in the explicit ancillary parameters.

  And in any case, you need the range-list syntax defined because it can be
used in MTIME as well as in WHERE.

  An apt analogy might be you go in to buy a new car and you find one you
like.  It comes with built-in seat heaters.  You're planning to move to
Florida soon, so you probably won't use them.  But otherwise the car is just
what you want.  Do you ask the dealer to take out the heaters, thereby
decreasing the value of the car for resale and adding cost up front?

  This is such an inordinate amount of fuss for such a small part of the
document, something that will be very useful to many data providers and
consumers.  Separating the Param/Query text into another document has a
significant cost in terms of process.  We have now spent another week
debating idealized -- and in this case, in my mind, irrelevant -- design
principles and not made one whit of progress in addressing the
organizational problems or technical questions.

  Can we please focus on how the core work is going to get done?  Who is
going to answer the technical questions that have been raised?  How are the
answers going to be reflected in the document?

Bob