[Bug 22733] New: [xslt 3.0] Setting defaults for a module/package

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

            Bug ID: 22733
           Summary: [xslt 3.0] Setting defaults for a module/package
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

With the spec as currently written, there are some attributes such as
default-mode and default-validation that can appear only on xsl:stylesheet, and
that affect everything in the stylesheet module. A careful reading of the spec
shows that declarations within xsl:override are not part of the stylesheet
module and are therefore unaffected by these attributes.

There are other similar attributes such as default-collation and
xpath-default-namespace that can appear on any element, including for example
xsl:stylesheet, xsl:package, or xsl:override, and that affect all descendants
of the element on which the attribute appears.

I suggest generalizing default-mode and default-validation so they behave like
the other attributes: that is, they can appear on any element (including
literal result elements in the form xsl:default-mode etc). This allows them to
be specified at the xsl:package level if the intent is to affect declarations
appearing within xsl:override, or at xsl:use-package or xsl:override level if
different defaults are wanted depending on which package you are overriding.

This leaves input-type-annotations. This is anomalous because it has to be
consistent across all the stylesheet modules in the stylesheet (as currently
written, this means it also has to be consistent across packages). I would
suggest that we make this a property of a package, and allow it to be defined
at the level of xsl:package; if it's defined at xsl:stylesheet level then this
must be consistent with the containing xsl:package. As for the semantics, it
should behave like xsl:strip-space, affecting all source documents read within
the scope of that package. We have an open bug to define exactly what that
means, but the issue is the same for strip-space and for stripping of type
annotations.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 19 July 2013 09:32:18 UTC