W3C home > Mailing lists > Public > public-xsl-wg@w3.org > April 2016

XSLT WG call 2016-04-28: Summary of technical discussions and decisions

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Thu, 28 Apr 2016 12:56:45 -0600
Message-Id: <62C19049-AEDE-4105-8A8D-9D0D8A45EC92@acm.org>
Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
To: Public XSLWG <public-xsl-wg@w3.org>
The XSLT WG met on Thursday 28 April 2016.

> 7. Spec bugs

> 29574 - [xslt30] Default visibility of accepted components
>        Needs to be discussed - outside WG

SCA asked ABr whether he still leaned toward making the change
suggested.

MK summarized the issue. If package B uses a package A, and A has a
public component C which is not mentioned in any accept or override in
B, then component C is visible to any user of B. Max Toro, the
originator of bug 29574, suggests that by default it should NOT be
public to users of B.

ABr agrees with Max Toro that in real world situations one doesn't
want to expose everything this way.

ABe suggested that it's really up to the author of package B to make
private whatever things in package A should *not* be exported from B.
After all, the author of B knows what those things are better than
anyone else. MSM suggested that that is likely to be true during the
initial development of B, but if two years later a maintenance
programmer is recompiling B against an updated version of A, which has
incidentally added some new components, that won't be the case. And if
the original developer of B used individual accepts for each name
exported from A, to make very clear and explicit that they were each
individually being made private, the new names will sail through and
become public merely because the maintenance programmer is not
touching B but merely recompiling against a new version of A.

ABe argued that if library A provides new functions, usually the users
of B will want to see them. Suppose A is a library of trig functions,
and a new version of A broadens the coverage of the library, so it
supplies some functions that were omitted from the first version.
Users will, ABe suggested, want to have access to the new functions.
MSM countered that if B is a library for drawing SVG diagrams, users
of B will not be looking to it for trig functions. If they want trig
functions, they should normally be importing A themselves.

After some further discussion, the WG converged on the view that we
think we should accept the proposal, unless complications arise in the
revision (in which case MK will bring the topic back to the group).

We confirmed that as far as we now know, the wildcard syntax
introduced in response to issue 29478 and mentioned in comments 1 and
2 of this bug can be used either to make all names imported from A
private (as argued in comment 1) or to make all those names public (as
would be needed by someone who likes the status quo and wants any new
components in package A to be passed through their package B to users
of B. (We imagined a convenience package whose purpose is just to make
functions from several libraries available with a single use-package
instruction instead of several.)

ACTION: MKay to record in bug 29574 that that we've accepted the
implicit suggestion and plan to make an appropriate change.

ACTION: MKay to prepare a proposal for bug 29574.


> 29558 - [xslt30] Incorrect namespace for JSON
>    marked resolved - needs to be closed.

The various bugs now marked Resolved should be closed.


> 29513  [XSL30] Definition of "potentially consuming" in Glossary not
> complete
>    editorial - no discussion necessary; MKay to close after a few more
> tests.

Discussed.  Still pending.


> 29507  [xslt30] A problem case for streamed grouping
>    Discussed April 7 with decision as follows:
>    RESOLVED: to resolve bug 29507 by accepting the proposal in comment 3.

ABr asked that we wait to close this until the text of the change is available
so that we can review the text first.

So agreed. Do not close this one yet; keep it open until the text is
published.




> 29499  [XSLT30] Global xsl:variable/xsl:param not in streamability rules
>     Needs to be discussed at April 28 meeting.

In comment 2, ABr identifies several situations which need attention;
we appear to be OK with respect to situation 1, but the current spec
doesn't seem to ABr to address the other situations.

We will need to come back to this again.

It would be useful to have some written discussion in the meantime.
Please discuss by email.

At this point, the top of the hour came, and we adjourned.



> 29492  [XSLT30] streamability of xsl:attribute-set may not be complete
>      Action item from 14 April meeting.
>      https://lists.w3.org/Archives/Public/public-xsl-wg/2016Apr/0006.html

> 29472  [XSLT30] Optionally allow xsl:stream to process a document *without*
> streaming  2016-03-10
>      Action item from 14 April meeting.
>      https://lists.w3.org/Archives/Public/public-xsl-wg/2016Apr/0005.html

> 8. Test bugs

>  From bugzilla  (open bugs)
>  Are there any that need to be discussed?



-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************
Received on Thursday, 28 April 2016 18:57:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 April 2016 18:57:17 UTC