W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2015

[Bug 29088] New: [xslt 3.0] visibility="abstract" on xsl:expose

From: <bugzilla@jessica.w3.org>
Date: Thu, 27 Aug 2015 08:38:25 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29088-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 29088
           Summary: [xslt 3.0] visibility="abstract" on xsl:expose
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          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
  Target Milestone: ---

It's an error to specify visibility="abstract" on a template, function,
variable, or attribute set unless the body of the component is empty.

There's no similar rule when a component is declared as abstract on xsl:expose.
Should there be? Or should the body just be ignored?

(It's not so much an issue with xsl:accept because you can only accept
something as abstract if it is already abstract in the used package.)

A slightly orthogonal point: for xsl:template we say

If the visibility attribute is present with the value abstract then (a) the
sequence constructor defining the template body must be empty: that is, the
only permitted children are xsl:context-item and xsl:param, and (b) there must
be no match attribute.

I wonder if (b) is too strict: should it say: "(b) there must be a name
attribute". Visibility is only relevant to named templates, but if we allow the
template to have both a name and a match pattern, I don't see why we shouldn't
allow the visibility attribute to define its visibility when used as a named
template, rather than requiring the visibility to be specified in a separate
xsl:expose declaration.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 27 August 2015 08:38:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:55 UTC