[Bug 26781] New: [XSLT30] An argument / proposal for removing xsl:expose

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 26781] New: [XSLT30] An argument / proposal for removing xsl:expose

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26781

            Bug ID: 26781
           Summary: [XSLT30] An argument / proposal for removing
                    xsl:expose
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

When xsl:stylesheet was a child of xsl:package it seemed to make sense to have
an extra layer of indirection for exposing elements of that child to the
outside world. Now that xsl:stylesheet is not a child anymore, I think the need
for xsl:expose is gone.

The only things xsl:expose can do is hide things:
- change public to private or final
- change final to private

These options are already available in the visibility attribute of the
declarations. Having the visibility attribute present, exposes them. If someone
wants a declaration hidden, they can change that attribute. I don't see the
need (anymore) for having an extra declaration that can change the already
statically present visibility.

The biggest use-case, I think, was to allow, at package level, to hide parts
that were introduced with xsl:use-package. However, that declaration has an
xsl:accept (by using hidden or absent), in which the user can decide to accept
or not certain items. Again, two ways to achieve, I think, exactly the same.

In short: my proposal is to drop xsl:expose. It also gets rid of potential vs
exposed visibility, which I think is a good thing.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26781] [XSLT30] An argument / proposal for removing xsl:expose

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26781

--- Comment #1 from Michael Kay <[hidden email]> ---
I don't think the use case for xsl:expose has gone away. The rationale was to
allow an existing collection of stylesheet code to be packaged without
modifying the code, by writing a package manifest which you now write in the
form

<xsl:package ...>

  <xsl:import href="existing-code.xsl"/>

  <xsl:expose ...>

</xsl:package>

Using xsl:expose here is more self-contained than trawling through all the code
adding visibility attributes; it's more appropriate when you don't own that
code, and it's probably a sensible approach if that code has to continue
working under XSLT 2.0.

The removal of the xsl:stylesheet level changes the way this manifest is
written, but it doesn't alter the need for the feature. We could argue that the
facility is "a bridge too far" and that the need is not strong enough to
justify the complexity, but that's a different argument.

I'm very reluctant to spend time on re-examining requirements at this stage, or
we will never finish.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26781] [XSLT30] An argument / proposal for removing xsl:expose

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26781

--- Comment #2 from Abel Braaksma <[hidden email]> ---
> I'm very reluctant to spend time on re-examining requirements at
> this stage, or we will never finish.

I understand, and I feel the same.

However, I think that either the requirement is not met (in which case we
should fix it, either by removing it, if the requirement has gone, or by
amending it), or I misread the spec.

If you do as you say:

<xsl:package ...>

  <xsl:import href="existing-code.xsl"/>

  <xsl:expose ...>

</xsl:package>

you end up with the default potential visibility, which is private. It is only
permitted, with xsl:expose, to change the potential visibility *down* (less
public), not *up*. That means that private can be "changed" to private, but
cannot be made public.

In other words, using xsl:expose in the above example has no effect, unless we
change the default visibility from private to public (I'd probably argue
against that, but it would, as a by-product, solve the issues with xsl:param's
visibility).

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26781] [XSLT30] An argument / proposal for removing xsl:expose

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26781

--- Comment #3 from Abel Braaksma <[hidden email]> ---
As per the minutes of the XSL WG of telcon 2014-09-25
(https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0053.html, members
only), the recorded decision was:

<quote>
RESOLVED: to close bug 26781 by adopting proposal (a) of ABr's message
[1]: if no visibility attribute is present on a declaration, the
visibility of a component is determined by the xsl:expose declarations
at the package level; expose can lower but not raise the level of
visibility (retaining current rules). However, we did not adopt the
proposal to rename xsl:expose.

[1] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0032.html

The result of this is that the priority of visibility specifications
is:

  - xsl:expose with explicit name (if more restrictive than the
    explicit value on the declaration)
  - visibility on the declaration itself
  - xsl:expose with wildcard
  - private

We agreed to mark bug 26781 as RESOLVED.
</quote>

This means that, given:

<xsl:function name="my:fun">...</xsl:function>

that the following will make this public:

1) <xsl:expose names="*" visibility="public" />
2) <xsl:expose names="my:*" visibility="public" />
3) <xsl:expose names="my:fun" visibility="public" />

This also means that, given:

<xsl:function name="my:fun" visibility="private">...</xsl:function>

that the same statements (1) and (2) above have no effect, and (3) will raise
an error (TBD).

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26781] [XSLT30] An argument / proposal for removing xsl:expose

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26781

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Michael Kay <[hidden email]> ---
Marking this resoved (see comment #3)

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