casting support

On Wed, Jun 01, 2005 at 11:01:40AM +0100, Dave Beckett wrote:
> 
> On Tue, 31 May 2005 18:35:13 +0100, "Seaborne, Andy" <andy.seaborne@hp.com> wrote:
> 
> > 
> > 
> > Dave Beckett wrote:
> > > 4. Casting support
> > > 
> > > We lost the foo:bar() vs &foo:bar() distinction some grammars back.
> > > which is syntax for a casting operation and an extension function.
> > > 
> > > I think overloading these is a mistake.  The spec defines a set of
> > > required casting operations named for their datatype like xsd:byte()
> > > This means you can take any literal and make a datatype of that form,
> > > with the value that the datatype defines.
> > > 
> > > In RDF itself, you can easily make a lexical form for any RDF
> > > datatyped literal in RDF/XML or other syntax, and you can do that in
> > > in SPARQL if you only want to talk about a constant datatype:
> > > "abc"^^dave:type.
> > > 
> > > However, if you want to use it in expressions you can't do much
> > > except use constants.  So whereas:
> > >   FILTER "abc"^^dave:type = "abc"^^dave:type
> > > is true by RDF rules, you can't take a variable ?x with the literal
> > > value "abc" and do:
> > > 
> > >   FILTER ?x^^dave:type = "abc"^^dave:type
> > > 
> > > however, if dave:type is one of the built-ins, you can:
> > >   FILTER xsd:integer(?x) = "10"^^xsd:integer
> > > 
> > > but you could previously, when we had syntax for it:
> > >   FILTER dave:type(?x) = "abc"^^abc:type
> > > 
> > > which does the *make an rdf datatyped literal* operation but is now
> > > used solely for functions.
> > > 
> > > So, I'd like a new operator CAST
> > >   CAST(URI u, Unicode string s) returning what would be written as s^^u
> > 
> > Does this include:
> > 
> > CAST(?x, "foobar")
> > 
> > that is, a dynamic cast?  
> 
> of course.  A static cast would be of little use.

I think the only functionality we get out of casting a binding to a
type with no defined support is the ability to compare it to another
binding of the same type. (If there is library support for this alien
type, then the query will only be useful on certain systems, and the
lack of interop on the query will make interop of casting moot.) Any
comparisons on an alien type will be strictly lexical; the same
functionality comes of casting both to str before comparing them.

Can you think of a query that will be interoperable if cast were added
to the language that you can't do with casting to string? 

> > This seems more like a constructor than a cast as the 
> > value is changed.  This would make compiling to SQL quite hard, I guess.
> >
> > What about language tags? Do you want
> > 
> > lang("chat", "fr")?
> > 
> > to complete the set?
> 
> Not particularly, somebody else might.

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.