W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2014

[Bug 24490] Rewriting expressions for streamability is mandatory but not clearly defined

From: <bugzilla@jessica.w3.org>
Date: Tue, 11 Feb 2014 11:11:34 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24490-523-WnXkodo45B@http.www.w3.org/Bugs/Public/>

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
We discussed this at length at the Prague face to face meeting.

Among the points raised:

- The paragraph in 19.1 uses the term 'equivalent expression', intended as a
reference to 5.6.3, but does not hyperlink it.

- The paragraph in 19.1 quoted in the issue description alludes to the inverse
of the equivalent-expression rule given in 5.6.3; it would be good to persuade
ourselves that that rule is reliably invertible.

- It appears at first glance that the rule of 19.1 may handle expressions which
cannot be rewritten by the stylesheet author even in principle, since it relies
on some notions that are not (readily? or at all?) expressible in XPath, such
as the child-or-top pseudo-axis.

- Expressions of the form //x/y are included in the subsets of XPath defined
for streamable processing by other WGs; it would be unfortunate were our
streamability analysis not to accept them without rewriting.

- If the algorithm proves elusive or complex, there was some sentiment in the
WG (at least one WG member) for relaxing the requirement from a MUST to a MAY;
if it proves easy and simple, there seems to be no strong reason to relax it. 
Different WG members expressed different attitudes towards the prospect of
requiring stylesheet authors to rewrite expressions to make them recognizable
as streamable; some expected authors to be willing to do this, others felt it
was an untenable usability burden.

- If the full equivalence algorithm proves problematic, a narrower algorithm
that addresses //x/y etc. directly might be a tenable fallback.

We'll need to come back to this after further work on the
equivalent-expressions algorithm.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 11 February 2014 11:11:35 UTC

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