W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2003

RE: Casting to types derived from xs:NOTATION

From: Michael Brundage <xquery@comcast.net>
Date: Thu, 14 Aug 2003 11:02:57 -0700
To: "'Caroline Rioux'" <crioux@decisionsoft.com>, "'Ashok Malhotra'" <ashokma@microsoft.com>
Cc: <public-qt-comments@w3.org>
Message-ID: <002901c3628e$4b10dbe0$6501a8c0@xpider>

My understanding is that the answers to your questions fall out of the
existing casting rules, which say essentially that
- casting a derived type to a supertype succeeds without changing the value
(just its type)
- casting from a supertype to a derived type succeeds only if the additional
validation rules of the derived type hold true
- casting across the hierarchy from type T1 to type T2 first casts up from
T1 to its base type, then across to the base type of T2, and then finally
down to T2, like the diagram below.

B1 ----> B2
 ^       |
 |       |
 |       v
T1       T2



So
- casting from my:notation to xs:NOTATION is fine
- casting from xs:NOTATION to my:notation is fine provided that the rules of
my:notation are satisfied
- casting from across the type hierarchy to my:notation, or from my:notation
to another type, is not allowed, because at some step you would end up
casting to/from the base type xs:NOTATION, and no such cast exists.



Michael Brundage
xquery@comcast.net

Writing as
Author, "XQuery: The XML Query Language" (Addison-Wesley, to appear 2003)
Co-author, "Professional XML Databases" (Wrox Press, 2000)

not as
Technical Lead
Common Query Runtime/XML Query Processing
WebData XML Team
Microsoft


-----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Caroline Rioux
Sent: Wednesday, August 13, 2003 8:44 AM
To: Ashok Malhotra
Cc: public-qt-comments@w3.org
Subject: RE: Casting to types derived from xs:NOTATION



Thanks!

> I'll add wording saying that types derived from xs:NOTATION as well as
> xs:NOTATION cannot be constructed or cast to.

Does this mean that the casting table now dissalows casting xs:NOTATION to 
xs:NOTATION?

Otherwise, '$var cast as my:notation' (where $var is of type derived from 
xs:NOTATION) is equivalent to 'my:notation($var)', which leads to a 
constructor function being needed!

Also, if we atomize a sequence of nodes whose type is derived from 
xs:NOTATION, does the dm:typed-value() accessor return a value of type 
derived from xs:NOTATION?

Thanks again,
Caroline

> 
> All the best, Ashok
> 
> > -----Original Message-----
> > From: Caroline Rioux [mailto:crioux@decisionsoft.com]
> > Sent: Wednesday, August 13, 2003 2:44 AM
> > To: Ashok Malhotra
> > Cc: public-qt-comments@w3.org
> > Subject: RE: Casting to types derived from xs:NOTATION
> > 
> > Thanks for the quick reply,
> > 
> > [I am looking at the latest public version of F&O, 2003-05-02]
> > 
> > I understand that you cannot construct xs:NOTATION, but it is not
> clear to
> > me from the specs that this applies to all types *derived* from
> > xs:NOTATION.  Are they disallowed as well?
> > 
> > I think this should be made clearer, since in the casting table we are
> > allowing casts from xs:NOTATION to xs:NOTATION, which implies that
> there
> > is some way to get a hold of a value of type xs:NOTATION or derived
> from
> > it.
> > 
> > Thanks again,
> > Caroline
> > 
> > On Tue, 12 Aug 2003, Ashok Malhotra wrote:
> > 
> > > Caroline:
> > > Which version of the F&O are you looking at?  The latest version
> > > disallows both constructing xs:NOTATION and casting to it.  I think
> this
> > > is the right decision given the context dependent nature of the
> > > datatype.
> > >
> > > All the best, Ashok
> > >
> > > > -----Original Message-----
> > > > From: public-qt-comments-request@w3.org
> [mailto:public-qt-comments-
> > > > request@w3.org] On Behalf Of Caroline Rioux
> > > > Sent: Tuesday, August 12, 2003 9:36 AM
> > > > To: public-qt-comments@w3.org
> > > > Subject: Casting to types derived from xs:NOTATION
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions regarding xs:NOTATION.
> > > >
> > > > 1. Does there exist a constructor my:notation(xdt:anyAtomicType)
> for
> > > > my:notation derived by restriction from xs:NOTATION?
> > > >
> > > > From F&O 5.2 'Constructor Functions for User-Defined Types':
> > > >
> > > > "For every globally-defined atomic type in the static context (See
> > > [XQuery
> > > > 1.0: An XML Query Language] that is derived by restriction from a
> > > > primitive type, there is a constructor function [...] whose effect
> is
> > > to
> > > > create a value of that type from the supplied argument"
> > > >
> > > > However F&O 17.15 Casting to xs:NOTATION states:
> > > >
> > > > "It is not possible to cast values of any other type to
> xs:NOTATION
> > > > because the validity of an xs:NOTATION value is context dependent
> and
> > > > cannot, in general, be determined."
> > > >
> > > > This appears inconsistent since, according to F&O 5.1,
> constructors
> > > are
> > > > equivalent to casting.
> > > >
> > > > 2.  If constructors for types derived from xs:NOTATION exist, how
> do
> > > > they work?
> > > >
> > > > According to F&O 17.5:
> > > >
> > > > "Casting across the type hierarchy is logically equivalent to
> three
> > > > separate steps performed in order. Errors can occur in either of
> the
> > > > latter two steps.
> > > >
> > > > * Cast the source value, up the hierarchy, to the primitive type
> of
> > > the
> > > > source.
> > > > * Cast the value to the primitive type of the target type.
> > > > * Cast the value down to the target type. "
> > > >
> > > > In the case of xs:NOTATION however:
> > > >
> > > > xs:string("http://example.com:jpeg") cast as my:notation
> > > >
> > > > (where my:notation is derived by restriction from xs:NOTATION)
> > > >
> > > > should be allowed (see XPath 2.0 Language 3.10.2 4.3), but the
> second
> > > step
> > > > above would fail, since casting from xs:string to xs:NOTATION is
> not
> > > > permitted.
> > > >
> > > > Thanks for any clarifications,
> > > > Caroline
> > > >
> > > > --
> > > > Caroline Rioux, Software Engineer           +44-1865-203192
> > > > DecisionSoft Limited
> > > http://www.decisionsoft.com
> > > > XML Development and Services
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > 
> > --
> > Caroline Rioux, Software Engineer           +44-1865-203192
> > DecisionSoft Limited
> http://www.decisionsoft.com
> > XML Development and Services
> > 
> 
> 
> 

-- 
Caroline Rioux, Software Engineer           +44-1865-203192
DecisionSoft Limited                        http://www.decisionsoft.com
XML Development and Services
Received on Thursday, 14 August 2003 13:56:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:13 UTC