W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2011

[Bug 11372] XSLT 2.1 (11 May 2010), Section 15.3: Merge-source default context

From: <bugzilla@jessica.w3.org>
Date: Wed, 08 Jun 2011 22:09:03 +0000
To: public-qt-comments@w3.org
Message-Id: <E1QUQvv-0001Af-GS@jessica.w3.org>

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED

--- Comment #1 from Michael Kay <mike@saxonica.com> 2011-06-08 22:09:02 UTC ---
I took an action at the Prague F2F to propose a solution to this one. It's
surprisingly difficult, and I think the reason is that the
merge-source/merge-input syntax and semantics are pretty dense. Having the two
"select" attributes in a one-to-one relationship with each other is
particularly confusing. I think we could do better if we refactored it.

I would like to propose collapsing xsl:merge-source and xsl:merge-input into a
single element with the syntax

  name = qname
  for-each = expression
  select = expression

If for-each is present then the merge-input selects multiple input sequences,
one for each anchor item selected by the for-each expression, which is used as
the context item for evaluating the select expression. If for-each is absent
then the merge-input selects a single input sequence, obtained by evaluating
the select expression, which is then evaluated using the context of the
merge-input instruction itself.

The select expression can be replaced by a contained sequence constructor; the
for-each expression can't.

I think this will make it much clearer what's going on.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 8 June 2011 22:09:09 UTC

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