W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2002

F&O WD: Issue 16: Is a constructor more than a different syntax for CAST?

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 9 May 2002 07:06:32 -0400 (EDT)
Message-ID: <781476921661.20020509120627@jenitennison.com>
To: public-qt-comments@w3.org
Hi,

You say that you want comments on Issue 16: Is a constructor more than
a different syntax for CAST?

I think that constructors are different beasts from casts since a
constructor implies that a literal string can be tested and converted
at compile time, whereas a cast implies that it should be tested and
converted at run time.

However, I don't think that the majority of users will understand this
distinction if a functional syntax is used for constructors; I think
that they will wonder why they can do xf:date('2002-09-05') but not do
xf:date(@date). There's a similar situation with the
processing-instruction() node test in XPath 1.0. Until quite recently,
I believed that you could do processing-instruction($piName) whereas
actually the processing-instruction() node test has to contain a
literal string. I suspect that the only reason this isn't a FAQ is
that people don't use processing instructions much.

So I think there are two options. You could change the syntax for
constructors, so that the string that's interpreted to construct the
value doesn't look like a string, perhaps by using a different
delimiter, for example:

  xs:date \2002-09-05\

Or you could merge casting and construction in a functional syntax,
and state that if the argument is a literal string, it's a static
error if the string is not in the correct format.

I think that merging casting and construction is more friendly to
users, as it also prevents people from making the "mistake" of using a
cast when they could use a constructor.

Cheers,

Jeni
---
Jeni Tennison
http://www.jenitennison.com/
Received on Thursday, 9 May 2002 14:45:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:22 GMT