Re: Re: Re: The Perils of Sudden Type-Safety in XPath

Michael,

> I think the suggestion that the date and time functions could go out of
> the core, and into a separate namespace, on the basis that they could be
> implemented in an XQuery or XSLT module, might be quite well received in
> some quarters - especially if you supplied an implementation! Some
> functions have already been removed from the core because it was argued
> that users could easily implement them themselves, and quite a few WG
> members are keen to reduce the size of the core library.

I'm heartened to hear this. I'll see what I can do on putting together such
an implementation; easier to do of course in XSLT2 than Xquery as there are
very few current reference implementations (if you know of one, PLEASE let
me know ... it'd make my work writing a book on the subject much easier!).
>
> I'm less convinced by the idea of separate modules for double, etc - I
> don't think we want to get to the point where every stylesheet starts
> with a standard set of 23 namespace declarations.

I provided this by way of example, though I'm inclined to agree that the
simple data-type functions would be better kept as core. I could see moving
all of these core functions into one of a maybe three modular namespaces:
numeric, string, and system (sequence and nodal functions and operators),
along with a mechanism that made it possible to default multiple namespaces
into the operating environment. This would work along the same lines
as -classpath in Java; i.e.,

import namespace 'http://www.w3.org/xquery/ns/system'
import namespace 'http://www.w3.org/xquery/ns/string'
import namespace 'http://www.w3.org/xquery/ns/numeric'

would automatically occur (and would likely be built in). I'll have to think
about it, but will try to get something shortly.

-- Kurt








> Michael Kay
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list