There is a case where handling the cast correctly is critically important: when you are dealing with an implementation where nodes are not typed. In this case, you *always* have to do a cast to inform the validator of the type of a particular value. The Saxon implementation works this way, and I couldn't find anything in the standard that says that implementation must have typed nodes -- so I don't think that they are doing anything wrong by requiring the cast. The problem that I face is that I don't know what XSD implementation my end users will be using, so I have to make sure that my XSDs work correctly no matter what. If your implementation can't handle the cast correctly, I'd be forced to write two versions of an XSD, one for Xerces (without casts) and one for Saxon (with casts) -- I find myself in this situation today and I don't think it's acceptable. As Michael noted in his previous email it's a total pain -- having to write implementation specific versions of an XSD defeats the purpose of having a standard in the first place.
Please fix this bug :-) Thanks, jOrGe W. On Jun 13, 2012, at 3:40 PM, Mukul Gandhi wrote: > Hi Michael & all, > Here are few new thoughts I've about these issues, and writing them > to list here for records. > > The XSD type xs:dateTime has the parent type as xs:anyAtomicType. So > if an XDM node reference already has a type annotation as xs:dateTime, > I see no good value to do an explicit cast on such a node reference > (except as a user-opted lexical style). > > A probably interesting analogy wrt explicit casts for type > xs:dateTime, can be made with the following example, > > The type xs:long has the parent type as xs:integer. So if an XDM item > reference has a type annotation as xs:long (let's call it $x), then I > definitely see value in doing an explicit case like xs:integer($x), > since the value space of xs:long is a subset of value space of > xs:integer and we could use the expression xs:integer($x) in contexts > where an xs:integer value is expected. And I do find, these scenarios > to be working fine with PsychoPath XPath2 engine. > > I do agree, that the inability to do explicit casts on xs:dateTime > references is probably a bug, but as I wrote above I see almost no > use-case value of making this fix. > > On Thu, May 24, 2012 at 1:32 PM, Michael Glavassevich > <mrgla...@ca.ibm.com> wrote: >> Hi Mukul, >> >> Regardless of the severity I agree with Jorge that it's a pain if you can't >> write an XPath expression which works with both (Xerces and Saxon) >> implementations. Can this issue with the explicit cast be fixed in >> PsychoPath? >> >> Thanks. >> >> Michael Glavassevich >> XML Technologies and WAS Development >> IBM Toronto Lab >> E-mail: mrgla...@ca.ibm.com >> E-mail: mrgla...@apache.org > > > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
