- markup (52)
- xml (7)
- xslt (21)
- atom (8)
- overlapping markup (2)
- schema (9)
- creole (4)
- xforms (1)
- pipelines (7)
- coding (2)
- dtll (1)
- genealogy (3)
- gtd (1)
- hardware (1)
- legislation (1)
- ontologies (2)
- unicode (1)
- web (24)
- google (3)
- rdf (6)
- rest (3)
- wikis (1)
- work (1)
- xpath (1)
- xquery (1)
- xtech2008 (3)
- life (26)
- children (5)
- equality (6)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (7)
- xtech (6)
- blog (7)
- drupal (3)
Re: Levenshtein distance in XSLT 2.0
Odd how appealing expressions like
for $p in (0 to string-length($string1)) return $p
are, even to experts! Fortunately, the optimizer quickly turns them into
(0 to string-length($string1))
It’s one of those things like writing (if ($x=true())…) - somehow we do it even though we know it’s grossly redundant.
I wonder if it’s worth inferring a type of “xs:integer+” for (0 to string-length($string1)) rather than the current “xs:integer*”? In this example we’re doing an unnecessary dynamic type check. No, probably not, special-casing based on single examples has to stop somewhere! Unless the example is in an important benchmark, of course.