Re: As I work over DTB

Axel Polleres wrote:
> 
> Dear all,
> 
> we still *only* have a subset of xpath/xqueryt functions and operators 
> covered... basically the ones from the list of paula originally 
> collected plus the casts and type checking functions added for the 
> supported datatypes...
> 
> I was asking myself whether we shouldn't provide  at least some base 
> built-ins for rdf:XMLLiteral and rif:text as well in sections?
> 
> For rif:text, I suggest:
> 
> rifBuiltinFunc:lang($literal) as xsd:string

> 
> Returns the language tag in lower case if in the current interpretation 
> $literal is in the value space of rif:test and an error otherwise.

(s/test/text/)

Agreed. I had suggested lang along with langMatches (both from SPARQL) 
some time ago and last time I looked there were place holders for them 
in the "issues" section of the DTB.

> For stripping off the string part, we should define a Cast from
> rif:text to xsd:string accordingly in section 2.3.2 Cast functions.

I had originally proposed a general str operator taken from SPARQL. Jos 
suggested there were problems with that, if that's true then at least a 
cast would indeed be useful.

> For rdf:XMLLiteral
> the most useful would probably be Xpath or XQuery builtin functions
> such as
> 
> rifBuiltinFunc:evalXPath($XMLLiteral, $XPath) as rdf:XMLLiteral
> 
> rifBuiltinFunc:evalXQuery($XMLLiteral, $XQuery) as rdf:XMLLiteral
> 
> 
> which works for $XMLLiteral if in the current interpretation is in the 
> value space of rdf:XMLLiteral and $XPath, $XQuery's interpretation is in 
> the value space of xsd:string and representing valid Xpath expressions 
> or XQuery FLWOR expressions...
>  I am afraid though extremely useful, not everybody wants to implement 
> full XPath/Xquery support in their engines...

Exactly. It depends on our conformance statement.

If DTB is a menu of standard builtins which different dialects can pick 
and choose from then including these would be reasonable. At the moment 
the DTB is specific to BLD and so including them pushes the BLD 
implementation cost up rather :-)

My suggestion would be to include them, with a caveat statement that 
they may not be required for conformance, and solicit feedback.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 27 March 2008 18:01:41 UTC