[Bug 17183] New: [FO30] Constructors for list and union types

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17183

           Summary: [FO30] Constructors for list and union types
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The text needs some further changes to handle the introduction of casting to
list and union types.

17.1, Constructor functions for built-in types, only mentions atomic types; it
should also cover the built-in list types.

Where it mentions new XSD 1.1 types, it should also name them (there is only
one: precisionDecimal has gone away).

The question of the return type of a constructor function for list and atomic
types requires some careful analysis. 

For a list type whose item type is atomic, the result type is A* where A is the
atomic item type (we can't be more precise and say A+ if the list has a
minOccurs facet of 1 or more, which applies to the built-in list types, because
the function will always return () if the input is ()).

For a union type that is a "restricted union type" (which in bug 17181 I
propose renaming as a "constructed union type") the result type of the
constructor function is that union type. For a union type that is derived by
restriction from a "restricted union type", by one or more restriction steps,
the result type is the "restricted union type" from which the target type is
derived. For any other union type (which I think means a union type whose
transitive membership includes union types that are not "restricted union
types", or whose transitive membership includes list types), the result type is
xs:anyAtomicType if there are no list types in the transitive membership, or
xs:anyAtomicType* if there are.

(But do we want to spell all this out? We could just say that the return type
is xs:anyAtomicType*, and leave the implementation to do better if it chooses.
I don't think there are any adverse consequences of specifying an over-loose
return type except on implementations that do static typing - which are surely
a dying breed?)

For a list type whose item type is a union type, similar reasoning applies...

Section 17.2 on constructors for QName and Notation should say something about
how the context is handled when such functions are used as named function
references, or located dynamically using function-lookup (or the useless but
permitted case of partial function application). We now allow context-sensitive
functions in such cases, and should mention this.

Section 17.3 contains the spurious example function name fn:my:hatSize.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 25 May 2012 10:15:59 UTC