This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4890 - 4.3.2 Filter Expressions - Normalization for standalone PrimaryExpr needed?
Summary: 4.3.2 Filter Expressions - Normalization for standalone PrimaryExpr needed?
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Recommendation
Hardware: All All
: P5 enhancement
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-29 05:36 UTC by Ryan Gustafson
Modified: 2007-07-29 23:30 UTC (History)
0 users

See Also:


Attachments

Description Ryan Gustafson 2007-07-29 05:36:25 UTC
4.3.2 Filter Expressions does not state explicitly how normalization of a standalone PrimaryExpr (e.g. empty PredicateList) should occur.  Compare with 4.2.1 Steps, which provides clarification in the corresponding standalone case.  Perhaps 4.3.2 could include similar rules for completeness/symmetry?

Presumably the intent is to normalize the standalone case w/ no special treatment (unlike 4.2.1)?  Something like:

[PrimaryExpr]Expr
=
PrimaryExpr
Comment 1 Michael Dyck 2007-07-29 22:35:05 UTC
> Presumably the intent is to normalize the standalone case w/ no special
> treatment (unlike 4.2.1)?  Something like:
> 
> [PrimaryExpr]Expr
> =
> PrimaryExpr

Asserting that normalization has no effect on PrimaryExprs would be incorrect. (Most kinds of PrimaryExpr, apart from Literals and VerRefs, can be expected to change under normalization.)

You'll often find that non-terminal N does not have an explicit normalization rule [N]_Expr == ...  (The main exception to this is cases where normalization has no effect.) Instead, normalization is defined on various more specific forms derived from N; collectively, they define the normalization of N.

I'm marking this issue as resolved INVALID, because that's the closest alternative to "reasonable question, but not a bug in the spec". If you agree with this resolution, please CLOSE the issue.
Comment 2 Ryan Gustafson 2007-07-29 23:30:04 UTC
Sorry, I didn't mean to use the notation which meant nothing needed to be done to normalize PrimaryExpr, but it appears I did.  I meant to indicate continue processing the child productions with no special action taken at the PrimaryExpr level.  If the preferred way to indicate this is to omit any mention of normalization rules, then that itself is the answer to the intent of my original question.  The spec reads as intended.  Thanks for the clarification, closing.