- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Thu, 28 Apr 2016 12:56:45 -0600
- To: Public XSLWG <public-xsl-wg@w3.org>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.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