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 5133 - xpath restrictions should be removed
Summary: xpath restrictions should be removed
Status: RESOLVED WONTFIX
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords:
Depends on: 4636
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-04 17:34 UTC by Virginia Smith
Modified: 2007-11-29 19:28 UTC (History)
0 users

See Also:


Attachments

Description Virginia Smith 2007-10-04 17:34:55 UTC
In section 4.2.1.1, the first 2 bullet points list restrictions on the xpath expression. I thought that, in the 1st F2F in Redmond, we agreed to remove these restrictions but that seems to have gotten lost. Couldn't find it in the minutes. 

For example, why restrict the union operator. Using this operator will not necessarily result in more than one result node.

I believe we discussed moving some of these restrictions to "guidelines" or "best practices."
Comment 1 Kumar Pandit 2007-10-24 03:58:07 UTC
Currently the spec adds restrictions on the xpath expression in order to create a profile of the xpointer() scheme used to encode a fragment identifier. We have already decided not to use the xpointer() scheme. 

Proposal: resolve this as "won't fix"

Once we decide on the new scheme (such as xpath1 scheme), we can then decide what restrictions to add on that specific scheme.
Comment 2 John Arwe 2007-10-25 13:18:55 UTC
I think this should remain in its current state.  As you point out, once we decide on the new scheme (4636, which 5133 is dependent upon) then we will deal with this one.  5133 will prompt us to have the right discussion at the right time (when 4636 is fixed).
Comment 3 Kumar Pandit 2007-11-28 06:15:19 UTC
Proposal:
Resolve this bug as "won't fix".

Reasons:
We have consensus on 4636 to define our own scheme that fits into the xpointer framework. The current bug deals with restrictions on the xpath used in the xpointer() scheme. Since we have decided to not use the xpointer() scheme, this bug is no longer relevant.