This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29957 - [XSLT30] Non-schema-aware processors and schema-attribute and schema-element node tests: error or not?
Summary: [XSLT30] Non-schema-aware processors and schema-attribute and schema-element ...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-22 22:18 UTC by Abel Braaksma
Modified: 2016-10-27 16:51 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2016-10-22 22:18:28 UTC 
In XPath, the descriptions of schema-attribute and schema-element node tests are in reference to the in-scope schema definitions (namely, the in-scope attribute declarations and in-scope element declarations).

If such declaration is not found, XPST0008 must be raised.

However, in XPath it is also defined that the test succeeds if the type derives-from the declared type, and the name matches.

In XSLT in contrast we say that any SequenceType other than xs:untyped and xs:untypedAtomic for as-clauses should raise error XTSE1660, but there's no mention of node tests.

It stands to reason (but couldn't find this) that the in-scope schema definitions are the empty set for non-schema-aware processors. But one could also argue that these definitions automatically include mappings for xs:untyped and xs:untypedAtomic for all elements/attributes.

It's unclear to me whether match="schema-attribute('foo', 'xs:int')" should be rejected, whether it should ignore 'xs:int' and match on 'foo', or whether, if rejected, it should raise XTSE1660 or XPST0008.
Comment 1 Michael Kay 2016-10-23 08:49:55 UTC 
>But one could also argue that these definitions automatically include mappings for xs:untyped and xs:untypedAtomic for all elements/attributes.

I don't quite see what form such an argument might take.

XSLT 5.3.1 says: The in-scope schema definitionsXP30 for the XPath expression are the same as the in-scope schema components for the stylesheet, and are as specified in 3.14 Built-in Types. [The reference should really include 3.15 as well.]

Section 3.15 says: The schema components included in the in-scope schema components (that is, the components whose names are available for use within the stylesheet) are the top-level element and attribute declarations and type definitions that are available for reference within the synthetic schema document. See [XML Schema Part 1] (section 4.2.3, References to schema components across namespaces).

If there is no import-schema, then the synthetic schema document contains no global attribute declarations, therefore schema-element(foo) refers to an attribute name that is not present in the in-scope schema declarations, therefore a static error occurs.

The error code XTSE1660 applies specifically to non-schema-aware processors, not to schema-aware processors when there is no imported schema, and there's room for debate about which error code takes precedence. But either way, "foo" is not in the in-scope schema declarations and therefore can't be referenced in schema-attribute().

XPath says "If the ElementName specified in the SchemaElementTest is not found in the in-scope element declarations, a static error is raised [err:XPST0008]." which seems pretty unambiguous to me.
Comment 2 Abel Braaksma 2016-10-24 09:36:19 UTC 
Somehow I came to the conclusion that if you use that type that it automatically exists (in that "give me an element X with type annotation Y").

But now I think that my reasoning took a shortcut. Using schema-element *requires* a declaration in a schema to be present for that element. That all elements are considered to be of type xs:untyped is irrelevant.

(conversely, if my argument were correct in any sense, using schema-element(x) would have little effect if it meant that any element existed automatically as xs:untyped element)

So, bottom line, schema-element() and schema-attribute() cannot possibly select anything for non-schema-aware processors and will always raise one of these two errors.
Comment 3 Michael Kay 2016-10-27 16:51:06 UTC 
Closed with no action.