[tmql-wg] TMQL, next round
rho at bigpond.net.au
Fri Mar 9 03:37:38 EST 2007
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
> 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 :-))
More information about the tmql-wg