This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test uses the constructor function s:lowercaseName, but s:lowercaseName is not a generalized atomic type because it has a pattern facet. Therefore the no such constructor function is available.
s:lowercaseName is also used in CastAs-UnionType-22 CastAs-UnionType-23 CastAs-UnionType-24
We now allow casting from string and untypedAtomic to any simple type other than the abstract types xs:anySimpleType and xs:NOTATION, with semantics equivalent to validation.
Thanks.
Can you clarify why a constructor function is expected for s:lowercaseName? http://www.w3.org/TR/xquery-30/#id-constructor-functions "For every generalized atomic type in the in-scope schema types (except xs:NOTATION and xs:anyAtomicType, which are not instantiable), a constructor function is implicitly defined." [Definition: A generalized atomic type is a type which is either (a) an atomic type or (b) a pure union type ]. [Definition: A pure union type is an XML Schema union type that satisfies the following constraints: (1) {variety} is union, (2) the {facets} property is empty, ..... s:lowercaseName has facets so it isn't a pure union type or a generalized atomic type. The test description is "Constructor function for union type with facets". Am I missing something?
I may have found it in 4.11 Schema Import: "For each named user-defined simple type in the schema, schema import also adds a corresponding constructor function. "
Also F+O 18.5: For every user-defined simple type in the static context (See Section 2.1.1 Static Context XP31), there is a constructor function whose name is the same as the name of the type and whose effect is to create a value of that type from the supplied argument. But XPath 3.14.4 has it wrong: "For every generalized atomic type in the in-scope schema types (except xs:NOTATION and xs:anyAtomicType, which are not instantiable), a constructor function is implicitly defined."
Thanks. I just noticed that bug 28915 already addresses this. I am changing this test suite bug back to INVALID since the issue is in the specification.