Re: TMQL: Minor issue: Plurals for paths

On 8 Mar 2011, at 3:17 AM, Xuân Baldauf wrote:
>> 
> I like this idea in general. However, this should only be done if we have succeeded in defining a generic "exactly_one" function (or axis, if you will) which picks along some still-to-be-defined rules an element of a set|collection (and raises an error of the collection is empty). 

Why would you raise an error if the collection was empty?  Standard API design is to return an empty collection for things that expect collections and null if a single value is expected, certainly not raising an error.  If you're trying to iterate over it, you'll just have an empty collection and no iteration.  If you introduce things that return null, then you need to also add operators and conditionals to test for this scenario into TMQL.

Is there a precedent you're following from somewhere for this idea?  Other query languages, e.g. SQL, certainly don't work this way.

This actually brings up something else I was wondering over the weekend:  in SQL, you have a set of tuples as the core underlying thing that is operated on within queries.  In XPath, you have lists of nodes.  When you want one, that's where distinct comes in (or things like :first-child), but you still get a tuple or a node, not single values from the primary query operation.  It seems like TMQL supports a mix of both approaches.

Is there a similar core concept of a "set of somethings" in TMQL?  In reading the drafts, it doesn't seem to indicate that there actually is.  My TMRM bias says that "something" should be a proxy (even an SQL tuple can be a proxy if you squint just the right way), but I don't imagine that would be a popular choice.

If there was some kind of unified view of what these functions always returned unless explicitly qualified with "distinct" or something similar, I think the necessity of an "exactly one" function described above would go away.  If you only want one, you either use distinct on some sub-selector or you just use #first or something similar from the host language.  Alternatively, you have to provide collection iterators/selectors as part of the core language the way XPath does.  While useful, it can't help but increase the complexity of both the spec and an implementation.

Again, to me it comes back to where and how we expect people to actually use TMQL.  Is TMQL alone intended to be sufficient to solve a certain class of problems, or is TMQL intended to be the semantic query "heavy machinery" embedded in other environments.  I think the answer there can help determine how far down the rabbit hole TMQL needs to go--at least for a first revision of the revision of the revision of the revised draft... ;)

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org