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

Our preference would be to provide a core set of functions combined with 
optional modules.  There is a definite advantage to having all the 
functions defined in a spec to ensure interoperability between 
implementations - this is obviously a benefit for users.  However, 
forcing a full implementation requires significant resources and is a 
hindrance to an attempt to put out a basic implementation.

As Michael Kay previously mentioned, the size of the library can often 
be inversely proportional to the success of the product, but full 
removal of all these functions could also lead to varying 
implementations, which would also give users a headache.

If the idea of optional modules were adopted then a developer such as 
Tobias could pick an implementation that satisfied his needs, or if none 
existed could find an open source one and contribute his own functionality.

Derrick Freedman


Michael Rys wrote:

>Would you prefer the reduction via removal or via making some functions
>optional (have optional groups of functions)?
>
>Thanks
>Michael
>
>  
>
>>-----Original Message-----
>>From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
>>request@w3.org] On Behalf Of Derrick Freedman
>>Sent: Wednesday, June 11, 2003 9:58 AM
>>To: public-qt-comments@w3.org
>>Subject: Re: SAG-FO-01: Too many functions (general comment)
>>
>>
>>As an XPath implementer I tend to agree that the function library is
>>    
>>
>too
>  
>
>>large.  Even updating the functions from one revision of the spec to
>>another requires significant resource, let alone implementing from
>>scratch.  The general consensus at DecisionSoft is that we too would
>>like to see the size of the function library reduced.
>>
>>Derrick Freedman
>>DecisionSoft Limited
>>
>>Kay, Michael wrote:
>>
>>    
>>
>>>Software AG believes that the size of the function library defined in
>>>      
>>>
>the
>  
>
>>>Functions and Operators document is too large.
>>>
>>>The size of the library directly affects the cost of implementation,
>>>      
>>>
>>which
>>    
>>
>>>experience shows is the major factor determining the success or
>>>      
>>>
>failure
>  
>
>>of a
>>    
>>
>>>proposed standard. It also affects the cost of learning to use the
>>>      
>>>
>>language,
>>    
>>
>>>which is another important predictor of success.
>>>
>>>It is clearly proving difficult for the working group to debug the
>>>specification completely: reducing the number of functions will
>>>      
>>>
>greatly
>  
>
>>>assist this task.
>>>
>>>Between CR and final Recommendation the working groups will be
>>>      
>>>
>required
>  
>
>>to
>>    
>>
>>>demonstrate interoperability of implementations. A large function
>>>      
>>>
>library
>  
>
>>>greatly increases the difficulty of this task, and means it will take
>>>      
>>>
>>longer
>>    
>>
>>>to get to Recommendation status. Again, any further delays in getting
>>>      
>>>
>the
>  
>
>>>specifications finished reduces the chance that they will succeed in
>>>      
>>>
>the
>  
>
>>>market.
>>>
>>>Giving users several ways to express the same thing makes it much
>>>      
>>>
>more
>  
>
>>>difficult for optimizers to detect common coding patterns and
>>>      
>>>
>optimize
>  
>
>>them.
>>    
>>
>>>A large function library therefore reduces the chance that common
>>>      
>>>
>>constructs
>>    
>>
>>>will be well optimized.
>>>
>>>Software AG proposes a number of simplifications to the function
>>>      
>>>
>library.
>  
>
>>>This message considers the general-purpose functions. A second
>>>      
>>>
>message
>  
>
>>will
>>    
>>
>>>address the functions concerned with handling of dates, times, and
>>>durations.
>>>
>>>Proposal: remove the following functions
>>>
>>>A1. fn:context-item()
>>>
>>>This is a trivial synonym for ".". No-one is likely to use it.
>>>
>>>A2. fn:current-date() and fn:current-time()
>>>
>>>These can be trivially derived from fn:current-dateTime()
>>>
>>>A3. fn:deep-equal()
>>>
>>>This is semantically complex and unlikely to meet everyone's needs
>>>      
>>>
>for
>  
>
>>>comparing equality. Users can write their own version to match their
>>>      
>>>
>own
>  
>
>>>needs. The use of deep-equal() in distinct-values() can be replaced
>>>      
>>>
>by
>  
>
>>>making distinct-values a (higher-order) operator instead of a
>>>      
>>>
>function:
>  
>
>>>   EXPR "with" "distinct" EXPR ("," EXPR )*
>>>
>>>A4. fn:distinct-nodes()
>>>
>>>This is likely to be needed very rarely and can be trivially written
>>>      
>>>
>as
>  
>
>>$x/.
>>    
>>
>>>A5. fn:empty()
>>>
>>>This is trivial syntactic sugar for count($x)=0, or not($x). The name
>>>      
>>>
>is
>  
>
>>>also misleading, since other XML specifications use the word "empty"
>>>      
>>>
>to
>  
>
>>mean
>>    
>>
>>>"having no children": users will make the mistake of thinking that
>>>      
>>>
>>empty(E)
>>    
>>
>>>is true if E is an element with no children.
>>>
>>>A6. fn:ends-with()
>>>
>>>The effect of this function can be readily achieved using the
>>>      
>>>
>>fn:matches()
>>    
>>
>>>function with a regular expression.
>>>
>>>A7. fn:exists()
>>>
>>>This is trivial syntactic sugar for count($x)!=0, or boolean($x).
>>>
>>>A8. fn:index-of()
>>>
>>>This is a rarely-needed function, and index-of($s, $v) can be readily
>>>rewritten as
>>>
>>>   for $i in 1 to count($s) return
>>>     if ($s[$i] eq $v) then $i else ()
>>>
>>>A9. fn:insert-before()
>>>
>>>The most common requirement is to insert at the start or the end,
>>>      
>>>
>which
>  
>
>>can
>>    
>>
>>>be achieved using the "," operator. The rare requirement to insert in
>>>      
>>>
>the
>  
>
>>>middle can be achieved using
>>>
>>>   ($target[position() lt $position], $inserts, $target[position()
>>>      
>>>
>ge
>  
>
>>>$position])
>>>
>>>A10. fn:item-at()
>>>
>>>The effect of this function can be easily achieved using a numeric
>>>predicate.
>>>
>>>A11. fn:node-kind()
>>>
>>>It is easy to test the kind of a node using "instance of" (or "type
>>>      
>>>
>>switch"
>>    
>>
>>>in XQuery)
>>>
>>>A12. fn:remove()
>>>
>>>The effect of this function can be readily achieved by writing
>>>$target[position() ne $n]
>>>
>>>A13. fn:sequence-node-identical()
>>>
>>>This function is very rarely required; if it is ever needed, it can
>>>      
>>>
>be
>  
>
>>>written as
>>>
>>>   every $i in 1 to max(count($arg1), count($arg2))
>>>       satisfies ($arg1[$i] is $arg2[$i])
>>>
>>>A14. fn:string-pad()
>>>
>>>This function can be readily written as
>>>
>>>  string-join(for $i in (1 to $padCount) return $padString, "")
>>>
>>>A15. fn:subsequence()
>>>
>>>Both variants of this function can be readily written using
>>>      
>>>
>positional
>  
>
>>>predicates:
>>>
>>>  $sourceSeq[position() ge $startLoc]
>>>  $sourceSeq[position() ge $startLoc and position() lt $startloc +
>>>      
>>>
>>$length]
>>    
>>
>>>Michael Kay
>>>Software AG
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>
>  
>


-- 
Derrick Freedman, Software Engineer    +44-1865-203192
DecisionSoft Limited                   http://www.decisionsoft.com
XML Development and Services