RE: Casting/constructors should accept the empty sequence

I don't like xs:int?().


I think using 

Expr cast as T
Expr cast as T?

And T(Expr) as a synonym for the later quite acceptable and do not see a
reason to change.

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Michael Kay
> Sent: Sunday, May 30, 2004 3:19 PM
> To: 'Ashok Malhotra'; Michael Rys; 'Ashok Malhotra'; 'Don Chamberlin'
> Cc: public-qt-comments@w3.org
> Subject: RE: Casting/constructors should accept the empty sequence
> 
> 
> Here is an out-of-the-box suggestion.  Remove the verbose cast syntax.
> Allow two signatures for each constructor function;
> 
> 	one that accepts the empty sequence and one that does not.  For
> example:
> 
> 	xs:integer(anyAtomicType)
> 
> 	xs:integer?(anyAtomicType?)
> 
> 	The only problem with this suggestion is that you will not be
able
> to cast/construct user defined datatypes defined in the null namespace
> 
> 	if the null namespace is used as the default namespace for
> functions.
> 
> 
> I quite like this.
> 
> We could solve the "null namespace" problem by changing the XPath
grammar
> so
> that wherever it currently uses the QName production, it is changed to
use
> a
> new construct NQName, where NQName allows either a lexical QName, or
> ":name"
> to refer to the expanded QName that has local part "name" and is in
the
> null
> namespace. (We could encourage XML and XMLSchema to adopt the same
> convention where they use QNames, but we could do it for XPath QNames
> independently).
> 
> Extending the syntax of function calls to allow xs:int?(3) is a bit
> tricky,
> and the effects might be a little pervasive. We could define it as
custom
> syntax, however. In fact, we could then make the parens optional,
allowing
> xs:int? 3
> 
> Michael Kay
> 
> 
> 
> 
> 
>

Received on Tuesday, 1 June 2004 02:26:33 UTC