RE: SAG-FO-01: Too many functions (general comment)

There is a great tendency for specs to grow too large. It is very easy to
add things, and much harder to take them out. By and large, the weight of
public comment has been that the language is too big - there are far more
complaints about having too many features than about having too few. If we
are going to correct that fault, we are going to have to be brutal: features
should only stay in if they are essential, not if they are "nice to have".

Making facilities optional can be a useful procedural device that reduces
the resistance to cutting things out. If it helps to get a decision made,
then fine. In principle, though, it's an unsatisfactory compromise.

The cost of having too many functions, as I tried to point out, is much
greater than the man-day of coding that it takes to implement each one. Each
function adds numerous test cases to the test suite, it adds to the weight
of user manuals and the length of training courses, it adds to the time
taken to get all the bugs out of the spec, it adds more time spent arguing
about differences between processors as revealed by interoperability tests.
And in particular, providing many different ways of coding the same thing
greatly reduces the chance that the optimizer will be able to spot a
particular pattern in your code and rewrite it efficiently.

The XSLT experience of the last few years has shown that if we only provide
a core function library, third party libraries will appear to fill the gaps.
Given that writing such function libraries is much easier for XSLT 2.0 and
XQuery 1.0 than it was for XSLT 1.0, I think we should work on the basis
that we don't have to put everything in the core.

Michael Kay


> -----Original Message-----
> From: Tobias Reif [mailto:tobiasreif@pinkjuice.com] 
> Sent: 12 June 2003 14:26
> To: public-qt-comments@w3.org
> Subject: Re: SAG-FO-01: Too many functions (general comment)
> 
> 
> 
> re 
> http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun
> /0082.html
> http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun
> /thread.html#82
> 
> Hi
> 
> I am a developer; not an implementer but a user of XSLT and XPath. If 
> the WG would scrap all those functions, I could implement 
> them myself, 
> in XSLT+XPath, but they wouldn't be as fast as they could be 
> when they 
> are implemented by the XSLT processor (or other XPath 
> implementation), 
> eg in C or C++.
> And I'd have to ship my implementation with each of my XSLT apps.
> 
> Thus the WG should continue to design and specify a comprehensive 
> standard library of useful functions.
> (Else, initiatives like EXSLT will.)
> A very small set of functions would leave too much to be 
> desired on the 
> side of the "user" (developer, not implementer).
> 
> Really redundant stuff like context-item() can be deleted.
> 
> But empty(), ends-with(), exists(), index-of(), insert-before(), 
> item-at(), remove(), subsequence(), etc (plus possible future 
> additions) 
> are *not* "trivial syntactic sugar", but are a lot more expresive and 
> clear than alternatives you list such as
> 
> for $i in 1 to count($s) return
>        if ($s[$i] eq $v) then $i else ()
> 
> [[for index-of()]]
> 
> 
> ($target[position() lt $position], $inserts, $target[position() ge
> $position])
> 
> [[for insert-before()]]
> 
> 
> The intent is expressed more directly; this aids maintainability. 
> subsequence() for example is very handy and expresses the 
> intend nicely 
> (pretty "self-documenting") when iterating over a sequence by 
> recursing, 
> when calling the current function with the rest of the sequence.
> 
> If implementers feel that implementing the whole lib is too 
> much work, 
> (remember that after having listed cost of implementation as major 
> motivation for your request, for nearly every functuion you emphasize 
> how simple it is to implement) then the spec could define an 
> additional 
> type of conformance level (in addition to schema-aware and 
> -unaware): One category of XSLT processors which implement 
> the standard lib, and 
> the other category of processors which do not. This should 
> satisfy all 
> the requirements or wishes of vendors such as those Software 
> AG seems to 
> have.
> 
> Then let each user decide which type of processor is more 
> useful for him.
> 
> Tobi
> 
> -- 
> http://www.pinkjuice.com/
>

Received on Thursday, 12 June 2003 12:53:54 UTC