fn:max and xdt:untypedAtomic

Help
marcvc
2004-07-14
2012-10-08
  • marcvc

    marcvc - 2004-07-14

    Michael,

    consider the following query:
      max (xdt:untypedAtomic("7")
    I would expect to get back as result an xs:double atomic value 7. Saxon 8 seems to return a xdt:untypedAtomic instance. Take for example the following query:
      typeswitch (max (xdt:untypedAtomic("7")))
        case xdt:untypedAtomic return "untypedAtomic"
        case xs:double return "double"
        default return "unexpected"

    I've also the impression that the current implementation is not in sync with the Saxon documentation for fn:max. It states:

    Implemented. Changed in 7.4 to support any comparable type. Changed in 7.8 to convert untyped Atomic values to xs:double, and to return NaN if the input sequence contains a NaN.

    Is this a (known) issue?

    Thanks,
    Marc

     
    • Michael Kay

      Michael Kay - 2004-07-14

      I think the W3C spec is unclear on this point and I will raise the question there before making any changes to Saxon.

      Michael Kay

       
    • Michael Kay

      Michael Kay - 2004-07-14

      On reading the latest internal F+O draft more carefully, I think it is clear that the result should indeed be the converted (xs:double) value. I've changed the code accordingly.

       
    • marcvc

      marcvc - 2004-10-26

      Michael,

      could it be that this has not been fixed in Saxon 8.1.1? I still see the same behaviour.
      In addition, something like:

      typeswitch (max (xdt:untypedAtomic("7"),xdt:untypedAtomic("8")))
      case xdt:untypedAtomic return "untypedAtomic"
      case xs:double return "double"
      default return "unexpected"

      Results in:
      java.lang.NullPointerException
      at net.sf.saxon.functions.CollatingFunction.getCollator(CollatingFunction.java:75)
      at net.sf.saxon.functions.CollatingFunction.getAtomicComparer(CollatingFunction.java:50)
      at net.sf.saxon.functions.Minimax.evaluateItem(Minimax.java:31)
      at net.sf.saxon.expr.ExpressionTool.eagerEvaluate(ExpressionTool.java:188)
      at net.sf.saxon.expr.FunctionCall.preEvaluate(FunctionCall.java:125)
      at net.sf.saxon.functions.CollatingFunction.preEvaluate(CollatingFunction.java:33)
      at net.sf.saxon.expr.FunctionCall.analyze(FunctionCall.java:113)
      at net.sf.saxon.expr.LetExpression.analyze(LetExpression.java:36)
      at net.sf.saxon.query.XQueryExpression.<init>(XQueryExpression.java:57)
      at net.sf.saxon.query.QueryParser.makeXQueryExpression(QueryParser.java:54)
      at net.sf.saxon.query.QueryProcessor.compileQuery(QueryProcessor.java:163)
      at net.sf.saxon.query.QueryProcessor.compileQuery(QueryProcessor.java:190)
      at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:168)
      at net.sf.saxon.Query.doMain(Query.java:318)
      at net.sf.saxon.Query.main(Query.java:69)

      Thanks,
      Marc

       
    • marcvc

      marcvc - 2004-10-26

      Michael,

      oops... of course the previous example shouldn't give a NPE. But that is not really what I wanted to demonstrate. Some brackets to create a sequence with 2 untypedAtomic values is misisng....

      max (xdt:untypedAtomic("7"))
      -> returns a xdt:untypedAtomic
      max ((xdt:untypedAtomic("7"),xdt:untypedAtomic("8")))
      -> return a xs:double
      max ((xdt:untypedAtomic("8"),xdt:untypedAtomic("7")))
      -> returns a xdt:untypedAtomic

      It looks like if the first value of the sequence is returned that the conversion to xs:double is not performed.

      Thanks,
      Marc

       
    • Michael Kay

      Michael Kay - 2004-10-27

      Thanks for reporting it. I've fixed both problems - the NPE that occurs when the second argument is an unknown collation name, and the failure to convert the first item in the sequence to a double when it happens to be the max or min of the sequence.

      Mike

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks