[tmql-wg] TMQL, next round

[Robert Barta]

On Fri, Mar 09, 2007 at 01:24:16AM +0100, Lars Marius Garshol wrote:
> 
> * Robert Barta wrote:
> >
> >Well, there is no _strict_ dependency, but I would find it somewhat
> >sleazy to offer a data type, but not the functions related with it.
> 
> There is no "the set of functions" associated with any particular  
> datatype, which I think is what's underlying the other Lars's point.

Hrm, well people with category theory background would probably
strongly disagree with you. They would argue that a type _IS_ actually
a product of all the functions available for a data structure. Keywords
"abstract data types", "encapsulation", "OO programming" (the real
one, not Java).

Older programming languages, though, such as C and Java probably do
not make this strong coherence. They see data types as sets and, oh by
the way, you can also have a function X doing something.

Maybe this is how most industry developers will see it.

> >So with xsd:string would come
> >
> >    http://www.w3.org/TR/xpath-functions/#string-functions
> 
> I think we could usefully cut this down to what XPath 1.0 had. We've  
> used that function set as predicates in tolog, and it's worked very  
> well for us. It also worked very well for XPath/XSLT.
> 
> >Of course, we can also say that this 'implementation', but then
> >compatibility is rather weak, not? And the standard is all about
> >compatibility....
> 
> Yes. So we have to balance compatibility of implementations against  
> complexity of implementations. If we lean too far over toward  
> complexity we get no implementations at all, and so theoretical  
> compatibility is no gain. :)

True, I would not underestimate the costs to implement a larger body
of functions even if you can rely on existing libraries. And it is
unbelievably boring, too :-))

\rho